The most expensive line on the bill is novelty
Every team has a finite budget for things that can go wrong in unfamiliar ways. Adopt a brand-new database, a fashionable framework, and an exotic deployment model all at once, and you’ve spent that budget three times over before you’ve shipped anything. When something breaks at 2 a.m. — and it will — you’ll be debugging three systems none of you has operated under load.
“Boring technology” is the deliberate choice to spend that budget carefully. It doesn’t mean old, and it doesn’t mean bad. It means well-understood: technology with a long operational track record, a deep bench of people who know its failure modes, and answers to your problem already written down somewhere.
Innovation tokens
A useful mental model is that you have a small number of innovation tokens. Each genuinely novel technology you introduce spends one. The number is small — for most teams, somewhere between one and three across an entire system.
This forces the right question: is this the place where novelty earns its keep? A new database engine might be worth a token if data is your core differentiator. A trendy front-end framework for a marketing site almost never is. Spend tokens where they create real, defensible advantage — and reach for the boring default everywhere else.
What “boring” buys you
The benefits are unglamorous and compounding:
- Known failure modes. When PostgreSQL misbehaves, the symptom is probably in someone’s blog post from 2014, with the fix below it. A six-month-old database gives you a GitHub issue with two thumbs-up and no answer.
- Hireable knowledge. You can staff a boring stack. The pool of engineers who can operate a mainstream toolchain is enormous; the pool who can operate your bespoke one is whoever you can poach.
- Operational muscle memory. Backups, monitoring, scaling, security patching — for mature tools these are solved problems with battle-tested runbooks, not research projects.
- Smaller blast radius. Fewer moving parts you don’t fully understand means fewer ways for an incident to surprise you.
This isn’t an argument against new things
It’s an argument for intentionality. New technology is how the industry moves forward, and sometimes the boring option genuinely can’t do the job. The point is to make that call on purpose, with eyes open, rather than by default because something was trending the week you started the project.
A good test: can you clearly articulate what the new thing gives you that the boring option can’t, and are you willing to own its failure modes in production? If yes, spend the token. If you’re reaching for it because it’s interesting, that’s a side project, not an architecture decision.
The senior move
Early in a career, reaching for the newest tool feels like progress. Later, you learn that the harder and more valuable skill is restraint — choosing the option that will still be obvious and operable to whoever inherits it.
The most senior decision is frequently the most boring one. Make it on purpose, write down why, and save your innovation tokens for the problems that actually deserve them.