Choosing a stack you won't regret in 18 months

Every stack looks good on launch day. The interesting question is what it looks like in eighteen months, when the person who built it has moved on, the framework has had two major versions, and you need one small change before a trade show.

The question nobody asks

Clients ask “which framework is best?” The more useful question is “what will this cost to keep alive?” Almost every regret we are asked to clean up traces back to a choice that optimised for the first two weeks of a project rather than the following two years.

The most expensive codebases we inherit are rarely the ones built with the wrong framework. They are the ones built with a framework nobody local can hire for, a hosting setup only one person understood, and a dependency tree that stopped receiving security patches.

Four tests we apply

Can you hire for it? If a technology has a thin hiring pool in your market, every future change routes through a specialist and prices accordingly. Popularity is not a technical virtue, but it is a commercial one.

Is it boring? Boring means the failure modes are documented, the upgrade path is published, and someone has already hit your problem on Stack Overflow. New is fun for the developer and expensive for the client. We keep the novelty budget for the one part of the product that actually needs it.

What does it cost at rest? A site with no visitors should cost close to nothing. Static output on an edge network costs pennies; an always-on server costs the same whether anyone visits or not. For most marketing sites and a surprising number of apps, the always-on bill buys nothing.

How does it fail? Ask what happens when the database is down, when a third-party API times out, when a deploy goes wrong at 5pm on a Friday. A stack with an obvious rollback is worth more than one with a slightly better benchmark.

What we usually land on

For content-led sites: static generation, HTML first, JavaScript added per component rather than per page. This site is built that way — Astro output on Cloudflare, no server to patch, and a rollback that is one click.

For products with accounts and data: Next.js or a plain React front end against a Node API, PostgreSQL when the data is relational (it usually is), and managed hosting so nobody on your side is responsible for kernel updates.

For anything with heavy background work: keep it out of the request path. A queue and a worker are less exciting than a clever synchronous solution and they will still be running next year.

None of this is controversial among people who have maintained software for a while. It only sounds unambitious if you are measuring ambition in framework releases rather than in years of uneventful uptime.