Choosing boring technology on purpose, added late

Greenfield advice is easy to write and not much use. This is the same idea applied to a system already carrying production load that isn't allowed to stop, with the compromises left in view.

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 code wasn't the hard part. Convincing production planners that a second reader wouldn't cause a revised instruction reached the floor after the batch had run was, because the last project that promised that did exactly that.

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.

We ran both paths against live traffic for three weeks and compared every work instruction. The mismatch rate started at four percent, all of it the old system's undocumented rounding.

WHERE IT GOES WRONG

• 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.
• A dependency with one maintainer sitting under the part of the system that handles money.

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

WHAT THE MIGRATION COST

Eleven weeks, one reverted step, nothing customer-visible. The reverted step was the one where we changed two things at once. We keep relearning that and we keep writing it down.