Every few months a new framework promises to change everything. Some do move the industry forward. Most just move engineering hours from one place to another. When a founder asks us "what should we build this in?", the honest answer is almost never about the framework first — it's about the constraints around it.

Start with the constraint, not the framework

Before we open a single terminal, we want answers to three questions: who is going to maintain this in eighteen months, how fast does the first version need to ship, and what does the product actually need to do that a generic stack can't. Those three answers rule out more options than any comparison chart.

Boring technology is a feature

A stack with a decade of production use has already had its sharp edges filed off by everyone who hit them before you. Documentation is thorough, the hiring pool is deep, and Stack Overflow already has the answer to your 2 a.m. bug. Novelty is a cost you pay every single day you run the product — in slower hiring, thinner documentation, and edge cases nobody has found yet.

Optimise for hiring, not for excitement

The team that ships v1 is rarely the team maintaining v3. A stack that's fun to write but hard to hire for quietly taxes every future release. We weigh how easy it will be to bring in a fourth or fifth engineer a year from now just as heavily as how fast we can move today.

When it's actually worth being experimental

None of this means "never take a risk." If a newer tool solves a real, specific constraint — performance at a scale your product will actually hit, or a capability nothing established offers — that's a legitimate reason to reach for it. The test is whether the choice is solving your problem, or solving our curiosity.

Our default stack, and why

In practice, that reasoning lands us on a fairly consistent set of tools across client work: a modern React-based framework for the front end, a typed language on the backend, Postgres unless there's a specific reason otherwise, and cloud infrastructure that a mid-level engineer can operate without a specialist on call. It's not exciting to write about. It's exciting to still be running smoothly two years after launch.

If you're mid-decision on a stack for your own product, we're always happy to talk through the trade-offs — no pitch attached. It's the same thinking behind our custom software and web development work.