Stack decisions get treated like brand decisions — a statement about who you are. That's backwards. A stack is a set of trade-offs you're agreeing to live with, and the only question worth asking is whether those trade-offs match the problem you actually have.
Our defaults, and why
Left alone, we reach for React and Next.js on the web, TypeScript everywhere, Node.js for services that don't need something else, and Postgres until there's a specific reason it won't do. Not because these are the best tools in the abstract — there is no such thing — but because they're boring in the specific way that matters: well-documented, easy to hire for, and unlikely to disappear in three years.
The three questions that actually change our answer
1. Who maintains this after us?
If you have (or plan to hire) a team that already knows a different stack well, matching it usually beats our default. A slightly-worse-fit technology your team already understands beats a theoretically-better one nobody can debug at 2am.
2. What's the actual load shape?
Most products never come close to needing the scalability story vendors sell. We size for the traffic you'll realistically have in eighteen months, not the traffic you'd have if everything went perfectly — over-provisioning for a hypothetical is its own kind of technical debt.
3. What does "wrong" cost here?
A stack choice for a payments system and a stack choice for an internal admin tool are different decisions, even if the traffic looks similar. Where the cost of a mistake is high, we lean toward boring and battle-tested. Where it's low, we're more willing to try something newer.
The best stack is the one whose failure modes you already understand.
What we actively avoid
- Adopting something because it was the top post on a forum last month
- Microservices for a team of two, before there's a real reason to split
- A framework with a maintainer count you could list from memory
// the question we actually ask, most of the time
const choice = pickStack({
teamFamiliarity: 'high',
expectedLoad: 'moderate',
costOfMistake: 'high',
});
// -> boring, well-documented, widely hireableThe short version
A tech stack is a set of trade-offs, not an identity. Match it to who'll maintain it, what load it'll actually see, and what a mistake would cost — and you'll rarely need to regret it a year later.