Choosing a technology stack you won't regret in two years

Stack debates tend to be conducted on the wrong criteria. Benchmarks, syntax preferences and framework popularity get argued at length, while the factors that actually determine whether a codebase is pleasant to work on in two years go unmentioned.

The criteria that predict regret

1. 01Can you hire for it? A stack with a shallow local talent pool becomes a retention problem the moment your first engineer leaves.
2. 02Is it boring in the places that matter? Novelty is affordable in a UI component and expensive in a database or a queue.
3. 03Does the ecosystem cover your non-core needs? Authentication, background jobs, file handling, admin tooling and payments should be solved problems, not projects.
4. 04How does it fail? Mature ecosystems have well-documented failure modes and answers to them. New ones have optimistic READMEs.
5. 05What is the upgrade story? A framework that breaks compatibility aggressively will consume engineering time indefinitely.

Where to be conservative

Be conservative about the layers that are expensive to change. PostgreSQL is the correct default for almost every application database, and the burden of proof sits firmly with any alternative. The same applies to your primary language and your cloud provider.

Be liberal about the layers that are cheap to change: styling approach, component libraries, build tooling. If replacing something takes a week, the decision does not deserve a month of debate.

A defensible default

For most business applications, a reasonable starting position looks like this — and every element is chosen for maintainability rather than for being interesting:

• TypeScript throughout, so refactoring is a mechanical operation rather than an act of faith
• Next.js or a similar server-rendering framework for anything users or search engines touch
• Django or FastAPI where the domain logic is substantial, or Node.js where a single language is worth more than framework depth
• PostgreSQL as the primary store, with Redis for caching and queues
• Docker for reproducible environments, with a managed platform for hosting unless there is a specific reason not to

The decision to document

Whatever you choose, write down why — in a short document that records the options considered, the constraints at the time, and the reasoning. When someone questions the choice in eighteen months, that document is the difference between a five-minute conversation and a rewrite proposal.