Pick a boring stack. Spend the novelty on the product.
A stack choice is a risk budget. Spend it on the thing customers pay for, not on the database underneath it.
The short version
4 things that decide this
- 01A team can only absorb so much unfamiliar technology before something breaks. Treat that as a fixed budget, not a free resource.
- 02Software engineer Dan McFunley named this the innovation token: a team gets roughly three per project, and every unproven tool spends one.
- 03Postgres, a mainstream framework and managed hosting are boring because their failure modes are documented. That is the whole argument for them.
- 04The product idea is where novelty pays. The plumbing underneath it is not the place to also be new.
A stack choice is a bet, whether you name it or not
Every founder picking a stack faces the same list: a database, a backend framework, a frontend framework, a hosting provider. Dozens of credible options exist for each. The temptation is to pick the newest one, because newest sounds like an edge.
It is not an edge. It is a cost, paid later, at the worst time. What breaks in production at 2am has no Stack Overflow answer. It shipped six months ago, and nobody has hit your exact bug yet.
The innovation token, and why three is the right number
Dan McFunley led infrastructure teams at Etsy and Slack. His essay "Choose Boring Technology" gave this problem a name worth keeping: the innovation token. A team has roughly three tokens to spend on a project, he argues. Spend them on unproven databases, unproven languages and an unproven deploy pipeline. There is nothing left when the product itself needs an unusual decision.
The number is not precise, and it does not need to be. What matters is that the budget is small and shared. A team debugging a two-week-old database driver on a Tuesday is not writing the feature that makes the product worth using. Every hour spent reading GitHub issues for a tool with forty stars is an hour the product did not get.
- 01A boring tool has years of documented failure modes, so a bug usually has a known fix
- 02A new tool's failure modes are still being discovered, often by you, in production
- 03Hiring gets harder for every unfamiliar piece: fewer engineers already know it, so onboarding and code review both slow down
What boring actually looks like
Boring is not a synonym for outdated. Postgres is boring, and it is also the database most new AI products reach for. It does relational data, full-text search and vector search in one place, with no second system to keep in sync. A mainstream backend framework is boring because a decade of production traffic already found its edge cases. Managed hosting is boring because someone else runs the pager for the parts of the system that are not your product.
None of this means never choosing something new. It means choosing where the newness goes. Say a startup is betting on a genuinely novel matching algorithm, or a pricing model nobody else runs. That product is already spending its risk budget on the part that earns money. An unproven database under the same product spends the budget twice, on a part that was never supposed to be interesting.
How to spend the budget on purpose
Before picking a stack, write down what is actually new about the product. That list gets the risk budget. Everything else gets the tool with the longest track record, the biggest community, and the most engineers who already know it.
If two options are close, pick the one more of your engineers have already debugged in production. A stack nobody on the team has broken before is a stack you will break together, for the first time, on a customer's data.
Questions this raises
01What is the best tech stack for a startup?
The one your engineers already know how to run in production, not the newest one. For most web and AI products, that means Postgres, a mainstream backend framework and managed hosting. Names matter less than a long track record of documented failures, so the team spends its attention on the product instead of the plumbing.
02Does choosing boring technology mean never adopting anything new?
No. It means being deliberate about where newness goes. Dan McFunley's innovation token framing treats novelty as a small, shared budget. Spend it on the part of the product that is genuinely new. Use proven tools for the database, the framework and the hosting underneath it.
03How do I decide what counts as boring enough?
Ask three things. Has it been in wide production use for a few years? Are its common failures documented? Do engineers you could hire already know it? A tool that fails all three is a spent token, whatever else it offers.
Related
- Best backend stacks for AI products →Where the boring-by-default argument gets specific about databases and frameworks.
- Supabase vs. Firebase →One of the concrete choices this argument applies to.
- Next.js vs. React →The same trade-off on the frontend side.
- Tech stack selector →A tool for narrowing the choice before you spend a token on it.
