There's a temptation in software engineering to reach for the newest, shiniest tool. A new database that promises 10x throughput. A framework that eliminates boilerplate. A language that makes concurrency trivial.
We've learned to resist that temptation — most of the time.
The innovation token budget
Every team has a limited budget for novelty. Dan McKinley called these "innovation tokens" — you only get a few per project. Spend them on your core differentiator, not on reinventing your deployment pipeline.
When we start a new project, we ask: where does this product need to be genuinely novel? That's where we invest our innovation tokens. Everything else gets the boring, battle-tested choice.
What boring looks like
For us, boring typically means:
- PostgreSQL over the database of the month
- TypeScript over languages with smaller ecosystems
- React over frameworks with uncertain futures
- Kubernetes over bespoke orchestration
- Terraform over clicking around in cloud consoles
These aren't exciting choices. They're reliable ones. And reliability compounds.
When we reach for something new
We break the boring rule when the problem genuinely demands it. If a client needs real-time ML inference at the edge, we're not going to shoehorn that into a REST API. If sub-millisecond latency matters, we'll reach for Rust or Go.
The key is being deliberate about it. Every departure from the boring path should come with a clear reason — not just enthusiasm.
The payoff
Projects built on boring technology are easier to hire for, easier to debug, and easier to hand off. They have better documentation, more Stack Overflow answers, and fewer "you're the first person to hit this bug" moments.
That's not a compromise. That's a strategic advantage.