How choosing boring technology on purpose broke an insurance claims system

The alert fired at a bad hour, as they do. The system wasn't down. That was the problem. It was up and confidently serving wrong answers, which is a lot worse than an outage because nobody comes looking.

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.

The trigger was boring. A reserve was released twice against the same loss. The system had no way to represent that, so it picked one, and adjusters spent the next day proving it wrong with exported CSVs.

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.

By the time anyone looked, about 15,000 claims a month had gone through the affected path. Only a slice of it was wrong, and we couldn't tell which slice without a full replay. The replay was the one thing we'd never tested.

WHERE IT GOES WRONG

• 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.
• 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.

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

WHAT CHANGED AFTERWARDS

Two action items survived: the two that removed a decision. Everything on the list that asked someone to be more careful was quietly dead within a quarter, which is roughly what we expected when we wrote it.