Every small team eventually faces the same decision: adopt the exciting new framework, database or platform, or stick with the dull one that already works. Nine times out of ten, the boring choice is the correct one — and the tenth time is usually a rationalisation, not an exception.
Novelty has a cost nobody puts on the invoice
New tools come with unknown failure modes, thin documentation, and a support community that’s still figuring things out alongside you. None of that shows up in a benchmark. All of it shows up at 2am during an incident, when the boring tool would have had five Stack Overflow answers and the exciting one has none.
This isn’t an argument against ever adopting anything new — it’s an argument for spending your “innovation budget” deliberately, on the one or two bets that actually matter to your product, instead of on every layer of the stack at once.
A rough rule of thumb
- If it’s not core to what makes your product different, choose the boring, well-documented option
- Adopt new technology for the problem you actually have, not the one you might have someday
- Budget one genuinely new bet per project, not one per developer
Boring technology means being able to reason about how it breaks. Exciting technology means finding out live.
The teams that ship reliably for years, not just for a good demo, tend to be the ones who made this trade-off early and stuck with it even when it wasn’t the fun answer.
