“What is the best stack” has no answer, which is why the discussion can run indefinitely and feels productive while it does. The answerable question is narrower: what will this specific system need to be true, in three years, for it still to be cheap to change?
That reframing does most of the work. It moves the decision away from benchmarks and toward four things that are boring, checkable, and much better predictors.
Four filters
1. How many people can work on it?
Not how many exist worldwide — how many you could realistically hire, in your market, at your budget, within a month. A technology with ten thousand practitioners nearby beats one with a million on another continent. This filter alone eliminates most of the interesting options, which is usually the correct outcome.
2. What does the release history look like?
Go back three years. Were there breaking changes, and how were they handled? Was there a migration path, a codemod, a long deprecation window — or a note saying the old way is gone? A project that has already carried its users through a major version transition once has demonstrated something no amount of current popularity demonstrates.
3. What does it cost to leave?
Every choice has an exit price. A library that formats dates is nearly free to replace. A framework that owns your routing, your rendering, and your data fetching is not. Spend the exit cost knowingly: pay it where the thing gives you real leverage, avoid paying it for convenience you could have written yourself in a day.
4. What breaks if nobody maintains it?
Assume the project is abandoned tomorrow. Does your system keep working indefinitely, keep working until something else changes, or stop? Most front-end libraries fail gracefully. Anything holding your data, your authentication, or your billing does not. Apply the most scepticism where the failure is worst, not where the decision is loudest.
Boring in the middle, interesting at the edges
The useful shape is not “everything boring”. It is boring where everything rests, and free to be interesting where a mistake is cheap.
The database, the authentication, the deployment, the language: choose the well-trodden option, and accept that the choice will be unexciting to defend. A visualisation library, a build-time tool, an animation approach: pick the better one, because replacing it later costs a week rather than a quarter.
Most stack regret comes from getting this backwards — novelty at the foundation, conservatism at the surface, where nobody would have minded either way.
What we build with, and why
We use Astro for content-driven sites, Next.js for applications, and Tailwind across both. None of those is a claim that they are the best available. They pass the four filters: we can hire for them, they have carried breaking changes responsibly, the exit cost is understood, and when something in that list eventually stops being the right answer, the parts of a system that matter most will not be the parts that have to move.
That last point is the actual goal. A stack that lasts is not one that never changes. It is one where changing a part does not mean rebuilding the whole.
- Architecture
- Astro
- Next.js