Choosing boring technology on purpose, seen up close in freight logistics

We spent six weeks inside a regional freight brokerage before we proposed anything. The brief said the problem was reporting. It wasn't reporting. Two days of watching dispatchers work through roughly 40,000 loads a month made that obvious, and dashboards had nothing to do with it.

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 clearest thing we saw was how dispatchers handled a contested load tender. On paper it's one step. In practice it's five, three of them over the phone, none of them written down. Which is why nobody could ever explain tender acceptance rate to their director.

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.

Here it showed up as a queue nobody owned. Roughly 40,000 loads a month went through it, and dispatchers had learned to check it twice a day because the alternative was two carriers were committed against the same trailer. A better queue wasn't the answer. Making ownership a property of the load tender was.

WHERE IT GOES WRONG

• 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.
• Confusing boring with old, and inheriting an unmaintained library because it felt safe.

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

WHAT WE TOOK AWAY

The work shipped and tender acceptance rate moved, but the thing we're proudest of is smaller than the system: dispatchers stopped keeping a private spreadsheet. That's usually the honest signal that the model finally matches the job.