Problem-shaped software, 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.

Most software people hate is software that was shaped by its tooling rather than by the job. The order matters more than the technology: understand the work, then build the thing that fits it. Reverse that and you get a system everyone has to be trained to tolerate.

THE WORK COMES FIRST

There's a moment in most projects where someone reaches for a product name before anyone has described the problem in a full sentence. It feels like progress. It's the opposite. Once a tool is in the room, the conversation quietly changes from what needs to happen into what that tool can be made to do, and nobody notices the substitution.

We try to hold off naming anything for the first week. Not out of purity. It's just that the constraints you discover in week one are the ones that decide the architecture, and you can't discover them while defending a choice you've already made.

HOW YOU KNOW IT FITS

A system that fits the work has a particular feel. The words on screen are the words people already use out loud. The states a record can be in match the states it's actually in. Nothing important lives in a comment field. When someone new joins, you explain the domain, not the software.

The tell for a bad fit is the shadow system. Every place we've worked that ran on software shaped by its tooling had a spreadsheet next to it, and the spreadsheet was where the real decisions got made. It's the most reliable diagnostic we know, and it takes ten seconds to run: ask what they keep outside the system, and why.

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.

THE COST OF THE WRONG SHAPE

Wrong-shaped software isn't usually slow or buggy. It's just permanently a little bit wrong, in a way that costs everyone twenty minutes a day and never rises to the level of a ticket. That's the expensive kind. A crash gets fixed. A daily twenty minutes gets absorbed into the job description.

It also compounds. Each workaround becomes something the next feature has to be compatible with, and after a few years the workarounds are load-bearing. By then the honest option is a rebuild, which is a much harder conversation than the one nobody wanted to have at the start.

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

• Picking the platform in the first meeting, then discovering the constraint that rules it out in week five.
• Naming things after the vendor's vocabulary instead of the client's, so every conversation needs a translation step.
• Treating the spreadsheet people already use as a symptom to be eliminated rather than a specification to be read.
• Shipping a system that works perfectly on the happy path, which turns out to be nineteen percent of cases.

Build around the problem first. Then build the system that fits it.

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.