Choosing a tech stack for a new product in 2026
A decision framework that starts from hiring, constraints and time-to-first-customer rather than from what is trending.
Stack choice matters less than teams think for the first year and more than they think for the fifth. The goal is to be fast now without being trapped later.
Optimise for who you can hire
The most elegant stack is worthless if you cannot staff it. Check the actual market you will recruit from — not the global conversation — before committing. This constraint quietly eliminates more options than any technical consideration.
Boring where it does not differentiate
Use the well-trodden choice for authentication, payments, storage and queues. Spend your novelty budget on the part of the product that is actually your product. Every unusual choice is a tax on onboarding, debugging and hiring.
What should decide the stack
Decides it
- Who you can actually hire in your market
- Data residency — often eliminates providers outright
- Offline or low-connectivity requirements
- Regulatory audit needs, which favour inspectable systems
Shouldn't decide it
- What's trending this quarter
- Benchmarks measuring a workload you don't have
- A novel choice for a component that doesn't differentiate you
- A managed service whose data you can't get back out
Let the constraints do the choosing
Most stack arguments dissolve once the real constraints are written down:
- Data residency requirements — often eliminates entire providers immediately
- Offline or low-connectivity use — reshapes the client architecture
- Real-time collaboration — a fundamentally different data layer
- Regulatory audit needs — favours boring, inspectable systems
- Existing team skills — the strongest signal, and the most ignored
Keep the exits open
You will be wrong about something. Keep business logic separable from framework specifics, avoid database features you cannot replace, and be wary of any managed service whose data you cannot get back out cheaply.
Keep the exits open
Do
- Keep business logic separable from framework specifics
- Prefer database features you could replace
- Check you can export your data cheaply
- Use the boring choice where it does not differentiate you
Don't
- Spend novelty budget on auth, payments or queues
- Adopt a managed service with no export path
- Pick a stack you cannot hire for locally
- Assume you will be right about everything
A default worth arguing against
For most business software: a typed language, a mainstream web framework with server rendering, a relational database, an object store, and a managed queue. It is unfashionable, it hires well, and it will carry you further than the alternatives will.