Every few months, something new shows up that promises to make your stack better: a new state management library, a new ORM, a new way to structure API routes. Adopting all of them feels like progress. Usually, it's just debt with better marketing.
Innovation tokens
There's a useful mental model here: treat your team's appetite for new technology like a limited budget of "innovation tokens." Every unfamiliar piece of tech you adopt — no matter how good it looks in a blog post — costs a token. Run out, and every incident, every onboarding, every "why is this breaking" investigation gets slower, because now your team is debugging unfamiliar tools instead of solving the actual problem.
This doesn't mean never adopt anything new. It means spending those tokens where they actually buy you something, and being honest about what "something" means:
- A new database because your current one genuinely can't handle your access patterns — that's a token well spent.
- A new database because a conference talk made it sound exciting — that's a token wasted on novelty.
Boring doesn't mean stagnant
"Boring" technology usually means: well-documented, widely used, predictable failure modes, and a hiring pool that already knows it. PostgreSQL is boring. REST over HTTP is boring. A monolith with a clean module boundary is boring. None of that means primitive — it means the hard problems in that space have mostly been solved by other people already, and you get to benefit from that instead of re-discovering the same edge cases they did.
The interesting, differentiated part of your product is rarely "which message queue we used." Spend your innovation tokens there instead — on the part of the system that's actually unique to what you're building — and let the rest of the stack be as unsurprising as possible.
A simple test
Before adopting something new, ask: if this breaks in production at 2am, how many people on the team can debug it without reading documentation first? If the honest answer is "just the person who picked it," that's not necessarily a reason to avoid it — but it is a cost you should account for, not a footnote.
