Why we chose problem-shaped software for discrete manufacturing

Written in the form we use internally, because the useful part of a decision record isn't the decision. It's the context that made it reasonable. In two years someone will want to reverse this, and they deserve to know what we knew at the time.

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.

We modelled it at about 30,000 units a week and the difference only showed up in the tail. At median load you couldn't tell them apart. At the ninety-ninth percentile, one of them stopped being able to explain itself.

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.

The deciding factor was regulatory, not technical. Production planners have to be able to reconstruct why a given work instruction was handled the way it was, months later, in front of someone unfriendly. That killed two of the three options on the spot.

WHERE IT GOES WRONG

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

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

CONSEQUENCES WE ACCEPTED

We took a slower first two months in exchange for a system you can still reason about in year three. On an eighteen-month horizon we'd have chosen differently, and we said so at the time.