How we choose a tech stack in 2026
There is no best stack — only the right trade-offs for your team, timeline and scale. Our decision framework.
Every few months a new framework promises to make everything else obsolete. Founders read the hype and ask us to build on it. Usually we talk them out of it — not because we are conservative, but because choosing a stack is a risk-management decision dressed up as a technical one.
Optimise for the whole lifecycle
The stack that gets you to a demo fastest is often the one that costs you the most over three years. We optimise for total cost of ownership: how easy is it to hire for, to onboard onto, to debug at 2am, to keep secure, and to still be maintaining happily in year three?
A framework with a tiny community and a single maintainer might be elegant, but when you hit a wall there is nobody to help you over it.
Boring is a feature
For anything that has to run in production and make money, we bias hard toward proven, boring technology. PostgreSQL over the database of the month. A mature framework over the one that trended last week. Boring technology has known failure modes, deep documentation, a large hiring pool and answers already written for the problem you are about to hit.
We save the novelty budget for the one or two places where it genuinely differentiates the product — and keep everything else deliberately unremarkable.
Match the tool to the team
The best stack for a client with a Python data team is not the best stack for a client whose two engineers live in TypeScript. Technology choices that ignore the people maintaining them are how you end up with a beautifully architected system that nobody on staff can safely change.
We ask: who owns this after we hand it over? — and let the honest answer shape the decision.
Our default answer
When there are no strong reasons to deviate, we reach for a small, sharp set of defaults we know cold: a modern full-stack JavaScript/TypeScript framework with server-side rendering, PostgreSQL for data, a typed query layer, and a managed platform for hosting. It is fast to build, cheap to run, easy to hire for and boring in all the right ways.
That is not dogma — it is a starting point we will happily abandon the moment the project has a real reason to. But defaulting to the well-understood, and spending your complexity budget only where it buys you something, is how you ship software that is still a pleasure to work on long after launch.
Frequently asked questions
Do you always use the same stack?
No — we have a set of well-understood defaults we reach for when nothing argues against them, but every project starts with the team, timeline and scale. The defaults are a starting point, not dogma.
Should a startup use the newest framework to move fast?
Usually not. Newness buys a little velocity on day one and charges interest for years. For anything that has to run in production, proven technology with a large community and hiring pool almost always wins over the total lifecycle.
How do you decide between building custom and using off-the-shelf?
We build custom only where it differentiates the product. For everything commoditised — auth, payments, email, hosting — we integrate proven services and spend the engineering budget on what makes the product uniquely valuable.
Keep exploring
Enjoyed this? We build the things we write about.
From first sketch to scaled platform — let's talk about your project.
Start a project
