Boring technology is a strategy, not a personality trait

Dan McKinley's "choose boring technology" essay introduced a useful framing: a team has a limited number of innovation tokens, and every unusual technology choice spends one. The tokens are finite because unfamiliar tools fail in unfamiliar ways, and debugging an unfamiliar failure at 3am is expensive in a way that does not show up on any evaluation spreadsheet.

Why boring is cheaper than it looks

PostgreSQL has been in production somewhere for decades. Every strange thing it does has been hit by someone, written up, and indexed by Google. When it breaks at an inconvenient hour, your problem is almost certainly someone else's problem from 2019, with a Stack Overflow answer attached.

A database released eighteen months ago has none of that. It might genuinely be better along the axis you evaluated. It also has an unmapped failure surface, and you will be the one mapping it, in production, under pressure.

Pinterest learned this in public

Pinterest's engineering team has spoken candidly about adopting a wide spread of specialised technologies during their steepest growth, then deliberately consolidating back onto a small set of mature ones. Not because the specialised tools were bad, but because operating many different systems has a cost that compounds quietly and does not appear in any individual decision.

Where to spend the tokens

The point is not to never adopt anything new. It is to spend deliberately, on the thing that is actually your differentiator.

If you are building a machine learning product, spend your tokens on the ML stack and run the boringest possible web framework around it. If you are building a real-time collaboration tool, spend them on the sync engine and use a database your team has used before. The exciting choice should be in the part of the system that is the reason your product exists — and nowhere else.

Teams get into trouble by spending tokens uniformly, ending up with a novel database, a novel queue, a novel deployment system and a novel frontend framework, none of which is their actual product.