Choosing a Tech Stack for Your Side Project

The stack that ships is the right stack. Scalability, “best practices,” whatever’s trending this month, none of it matters as much as whether you’ll actually finish the project. Here’s how to decide quickly instead of stalling on it.

Start with what you already know

If you’re proficient in a language and framework, that’s your default unless something concrete says otherwise. Learning a new stack while building a new product idea at the same time doubles the ways a project can stall. You’re debugging your understanding of the tools and the feature at once, and it’s easy to mistake the first kind of friction for a sign the idea itself isn’t working.

Save “learn X” for a smaller, disposable project. Build a todo app in the new framework with zero pressure to make it good, then bring the skill to the real project once the unfamiliar parts stop being unfamiliar.

Be honest about what the product needs

It’s tempting to reach for the tool you want to use rather than the one the product needs. A few honest questions:

Mostly content, low interactivity? A static-first framework will be simpler than a full app framework solving problems you don’t have. Real-time features like chat or live collaboration? You need WebSockets or something built around them, and that decision touches your hosting choice too, so make it early. User accounts and data that has to persist? Auth and a real database from day one, not bolted on later; retrofitting auth onto an app that wasn’t designed for it is a common way side projects die mid-rewrite. Just validating an idea? Consider skipping a custom backend entirely. A form tool or a spreadsheet as a database gets you a working prototype in a day, and a prototype that proves nobody wants the idea saved you the week you’d have spent building it properly.

A worked example

Say the idea is a habit tracker: users sign up, log daily habits, see streaks. No real-time features, but real interactivity (forms, charts, per-user state) and real user data that has to persist. That’s an app, not a content site, so it points at Next.js rather than Astro, plus Supabase for the database and auth in one vendor (RLS switched off until the data model settles, added once it does) and Vercel for hosting since nothing here needs a persistent connection. Total decision time: about ten minutes, because the requirements did most of the deciding once you actually wrote them down instead of jumping straight to “what should I build this in.”

Optimize for one thing: shipping

If two options are roughly equivalent in capability, pick the one with fewer services to configure, a framework you can deploy with git push rather than a manual setup you’ll forget the steps to next time, and documentation you can actually find when something breaks. A niche tool with a thin community means debugging alone at 11pm, and that’s worth avoiding almost regardless of how elegant the tool is otherwise.

A default that’s fine for most people

Not the “best” stack in any absolute sense. It’s the stack with the least friction between an idea and a deployed URL, and that’s the metric that actually predicts whether something gets finished. TypeScript across the whole stack is my own default, mostly because it means one language and one set of tooling for both ends of the app. Python is where I go instead, but specifically for scripting or a small standalone API that isn’t sharing code with a frontend anyway.

Most side projects that stall didn’t die from a bad framework choice. They died from three weekends spent comparing frameworks instead of one weekend spent building. Pick something reasonable, set a deadline for the first deployed version, and let the actual product tell you what needs to change from there.