The case for boring technology
January 25, 2026
Every new project is a chance to try something new. New framework. New database. New deployment strategy. And every time, you should probably resist.
There's a reason experienced engineers reach for boring technology. It's not lack of curiosity. It's pattern recognition. They've seen what happens when you bet on the wrong abstraction.
Innovation tokens
Dan McKinley has this concept of "innovation tokens." Every team gets a limited number of them. Spend them on things that actually differentiate your product, not on reinventing deployment.
Your users don't care if you're using the hot new database. They care if your product works.
The hidden costs
New technology has costs that don't show up in the README:
- Learning curves eat into shipping time
- Edge cases aren't documented yet because nobody's hit them
- The ecosystem is immature. That plugin you need doesn't exist
- Hiring becomes harder. Fewer people know the stack
- When things break, Stack Overflow can't help you
When to be boring
Be boring by default. Use the technology you already know. Ship faster. Save your innovation tokens for the parts of your product that actually need to be innovative.
Postgres is boring. React is boring. That's a feature, not a bug.
When to take risks
Sometimes new technology is the right call. When the boring option genuinely can't solve your problem. When the new thing is so much better that the switching cost is worth it. When you're building something where the technology itself is the product.
But be honest about which situation you're in. Most of the time, you're not building something that requires cutting-edge tech. You're building something that requires shipping.