Problem-shaped software: a cost model for credit operations

The question is never whether something is worth doing in the abstract. It's whether it's worth doing at your volume, with your failure rate, valuing your team's time properly. So let's do the sum.

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.

At around 2,500 applications a month with a two percent exception rate, underwriters were absorbing about nine hours of manual reconciliation a week. That's the number the build had to beat, and it's a lower bar than anyone in the room expected.

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 interesting term wasn't engineering time. It was the cost of an approval was issued against a stale valuation landing once in the wrong quarter, which the client could size to the pound and we couldn't size at all.

WHERE IT GOES WRONG

• 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.
• Treating the spreadsheet people already use as a symptom to be eliminated rather than a specification to be read.

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

WHERE THE MODEL BREAKS

Do the numbers before the meeting, not during it. A decision that survives arithmetic tends to survive the next reorg too, because the reasoning outlives the people who made it.