A stack is a set of slots, and every project fills the same ones. The arguing online is about which option goes in each slot, and almost none of that argument applies to one person trying to finish a side project. What decides your outcome is how much unstuck time you spend, and that depends more on how well documented your choices are than on how good they are.
The idea
Fix the slots first, then fill them. You need something to draw the interface, something to run code on a server, somewhere to keep data, something to handle accounts, and somewhere to run it all. Some options cover several slots at once, and for a solo builder that is worth more than any individual component being the best available. The The set of technologies a project is built from, taken together. you can finish beats the stack you can defend.
SLOT COMMON OPTIONS GOOD AT
------------------------------------------------------------------------
interface React huge ecosystem, most
examples in existence
Svelte less code per feature,
simpler mental model
framework Next.js (React) frontend + backend in
(both halves) one project, deploys easily
Ruby on Rails conventions for everything,
very fast for CRUD apps
Django (Python) mature, batteries included,
strong admin interface
data + accounts Supabase Postgres you own, auth and
storage included
Firebase realtime by default,
very little setup
hosting see chapter 5
------------------------------------------------------------------------
one project fills every row. bundles fill more than one at a time.How it works
The interface layer draws what the user sees. React is the most widely used, which mostly means every question you have has already been answered somewhere. Svelte does the same job with less ceremony and fewer people to ask.
A full-stack A prepackaged set of decisions about how a project is structured, so you write features instead of plumbing. covers the browser and the server in one codebase. Next.js is React on both sides and is built to deploy as one unit. Rails and Django are older, come with an opinion about everything, and give you a working admin screen and database tooling out of the box, which for a data-heavy app is a large head start.
Supabase and Firebase fill the data and accounts slots together. Supabase is Postgres, so what you learn transfers and you can leave. Firebase is Google's, stores documents rather than tables, and handles realtime updates with almost no work.
Nothing above is a recommendation. Every one of these has shipped serious products.
What to do
- Write down your five slots and fill each one with a name before you write code. Ten minutes.
- Weigh how much public example code exists for the combination, because that is what your AI assistant learned from. Next.js with Supabase produces confident, current output. An unusual pairing produces plausible code that quietly uses an API which no longer exists.
- Prefer the option that fills two slots when you are working alone. Fewer moving parts is fewer things to debug at midnight.
- Then stop choosing and start building. The stack decision has a short half-life and the project does not.
Where it breaks
Bundles trade freedom for speed, and the bill arrives late. Firebase's data model is genuinely hard to leave once you have a year of documents in it, which is why "can I export this" is worth asking on day one. The AI-familiarity criterion also has a bias built in: it points at whatever was popular in the training data, and it will happily write you 2023's Next.js in a 2026 project. And no stack saves a project from the actual failure mode, which is that nobody wanted the thing. That decision sits above all of this.