A rule of thumb for choosing boring technology on purpose

Somewhere between a principle and a habit sits the useful kind of rule: right most of the time, and wrong in ways you'll notice straight away. This is one of those.

Novelty is a budget, and it's smaller than you think. Spend it on the part of the system that's genuinely new to the world, and buy everything else off the shelf in the most boring form available.

THE NOVELTY BUDGET

Every unusual choice costs you the same things: fewer people who can debug it, thinner documentation, worse answers when you search the error message at midnight. That's affordable once or twice in a system. It isn't affordable eleven times, and eleven is easy to reach one reasonable decision at a time.

So we ask what's actually novel about the work. Usually it's one thing: a scheduling constraint nobody else has, a settlement rule that's genuinely peculiar, a workflow that doesn't exist in any product. That gets the interesting engineering. The web layer, the queue, the database all get the boring answer, and boring means the one with a decade of other people's bug reports behind it.

BORING IS NOT THE SAME AS OLD

This gets misread as nostalgia. It isn't. Boring means well-understood, widely deployed, and easy to hire for. Plenty of recent tools qualify, and plenty of old ones don't. An unmaintained library from 2011 is exciting in exactly the way we're trying to avoid.

The practical test: if this breaks at 2am, how many people on the team can fix it, and how good are the search results? If the answer is one person and a GitHub issue with no replies, you've spent novelty budget without meaning to.

Checked against credit operations: at around 2,500 applications a month it holds comfortably. It'd start to wobble an order of magnitude higher, where the fixed costs it ignores stop being small.

SAYING IT TO CLIENTS

Clients sometimes want to hear that their system is built on something impressive. We've found it lands better than expected to say the opposite: that the interesting engineering went into their actual problem, and everything else is deliberately dull so it keeps working when we're not looking.

That framing also sets up the honest conversation about where we did take a risk, and why. One flagged risk is a decision. Eleven unflagged ones are a liability nobody sized.

The rule would have caught an approval was issued against a stale valuation and didn't, because nobody applied it to the integration written under deadline. That's the usual story. The heuristic is fine, the coverage isn't.

WHERE IT GOES WRONG

• Confusing boring with old, and inheriting an unmaintained library because it felt safe.
• Eleven interesting choices, each defensible alone, none of them documented as a risk.
• A dependency with one maintainer sitting under the part of the system that handles money.
• Choosing a tool for the greenfield build that nobody wants to be on call for in year two.

Spend novelty on the part of the problem that's genuinely new. Buy the rest boring.

WHEN THE RULE FAILS

Treat it as a prompt to think, not a substitute for thinking. Its job is to stop the same conversation happening a fourth time, not to end it.