Why I'm Building 6 Backend Projects in 6 Different Stacks

Most advice for early-career backend engineers eventually collapses into "pick a stack and go deep." That's good advice — and it's also not quite what I'm doing right now, on purpose.

Over the next stretch of my roadmap, I'm building backend projects across six different ecosystems: Node/Express, Python (Django and FastAPI, which I'm treating as two different things on purpose), PHP (Laravel), Go, and Rust. Not six microservices bolted together — six separate projects, each picked because its problem actually fits its stack, not the other way around.

The thing I'm avoiding

The failure mode I'm trying to avoid isn't "knows too many languages, not deep enough in any." It's the opposite one: becoming a "$framework developer" who can build anything as long as it looks like the last five things they built, and who reaches for the familiar tool even when it's the wrong shape for the problem. Depth in one stack is necessary. It isn't sufficient if you've never had to feel a different stack's tradeoffs against your own skin.

How the stacks actually map to problems

This is the part that matters more than the "six stacks" framing suggests — each choice is a response to something specific about the project, not a checklist:

Node/Express — TutorLink. Full-stack JavaScript keeps one mental model end to end for a matching-and-scheduling app whose data shape is still finding its final form, which is exactly where MongoDB's schema flexibility is a genuine asset instead of just a default.

Laravel. A production, externally-facing system with a real stakeholder wants a framework that's already solved auth, queues, and admin tooling, so the actual engineering time goes into what's specific to the problem rather than re-solving what the framework already handles well.

FastAPI — Waqt. Async-friendly business logic — spaced-repetition scheduling, real external API calls for prayer times — is exactly what FastAPI's async model is built for.

Django — CS Compass. Structured, prerequisite-heavy curriculum content is a content-management problem before it's anything else, and Django's admin panel is the fastest path from "I have a data model" to "I can actually author content into it."

Go — SysLens. Low-ceremony, direct access to syscalls and /proc, plus static binaries that are trivial to run on a real machine — the right tool for a project whose entire point is looking underneath the abstractions other languages would hand you for free.

Rust — ChainSeed. An ownership model that maps directly onto the class of bug — shared mutable state across concurrent peers — that a naive blockchain implementation runs straight into.

NestJS (GigFlow) and Next.js + Supabase (VimAscend) round out the roadmap on the same logic: enforced structure for a SaaS-shaped admin tool, a relational data model for a curriculum graph that a document database would fight.

What "done" looks like

Not all six finished by some deadline. TutorLink is the one currently getting real hours; the rest are scoped, reasoned through, and waiting their turn, in roughly the order laid out on the projects page. "Done," realistically, looks like being able to explain — with a working project behind each claim — why a given problem fits a given stack, instead of explaining why my one stack fits every problem I'm handed.

That's also, not coincidentally, the version of "backend engineer" I'd want to hire.