Why I stopped designing the better process and started shipping the one they already run.

For five sprints I built a system nobody used.

Not a bad system. The models were clean. The stages mapped properly. The architecture would have survived a careful review. It ran on mock data and had exactly zero users. I know the number because I went looking for it.

Five sprints of work derived from documents, waiting on a data log the client kept promising to send. Every sprint the scope rolled forward under a new ID. Every sprint the answer was the same: we can’t validate it yet — the log hasn’t arrived.

The log was never going to arrive. And even if it had, I would have been validating a process I’d only ever read about.

The Remake Trap

Here’s what software people (including me) do.

A client shows you their process. It’s messy. Paper forms, a spreadsheet, someone’s handwriting, a step that exists because of a decision made eleven years ago. You look at it and instantly see the better version.

So you build the better version. You call it a remake, a transformation, or a digital-first redesign. Everyone nods, because everyone can see the mess.

Then you spend months building something that can only be validated at the end, all at once, against a process you inferred from paperwork.

That’s the trap. Not the ambition — the sequencing. You’ve made being wrong as expensive as it can possibly be, and you’ve scheduled the discovery for the last possible moment.

A User Before a Model

The turn came from a simple question I should have asked much earlier: what does someone actually do today, with their hands, right now?

The answer was unglamorous. Two paper logbooks come off the floor. Someone in quality control sits down and types them into a spreadsheet template. Every day.

That’s the process. Not the elegant nine-stage chain I’d modelled — a person, a stack of paper, and a spreadsheet.

So the first module stopped being a model of the business. It became a form that replaces that spreadsheet.

Five sprints of modelling produced no users. One real form, filled by one real person, produces one. That sounds small. It is the whole thing.

A model is an argument about the business. A user is a fact about it.

The Only Kind That Gets Adopted

Typing a logbook into a spreadsheet is double entry. The information already exists — someone is simply copying it from paper into a grid. Replacing that spreadsheet with a form doesn’t add a step to anyone’s day. It deletes one.

Compare that with the version I would have built six months earlier: screens in front of the floor operators so they capture each form at the source. Cleaner data. Better architecture. In many ways the superior design.

But it also adds work to people who are already busy, often with their hands full. That kind of system rarely fails at launch. It fails quietly a few weeks later, when the paper comes back and nobody tells you.

Digitisation that removes work gets adopted. Digitisation that adds work gets tolerated for a fortnight. That distinction has almost nothing to do with the quality of the software.

Change One Thing, Not Two

A remake changes two things at once: the tool and the process.

When something goes wrong — and something always goes wrong — nobody can tell you which one broke. The operator can’t separate “this software is confusing” from “this isn’t how we do it.” You’ve destroyed your own feedback signal on day one.

Building the current process changes exactly one thing: the tool. The work stays the same work, in the same order, with the same fields, in the same sequence the person already has in muscle memory.

Now when they say something’s wrong, the answer is unambiguous. It’s the tool. Fix the tool.

Process change comes later — with the operator in the room, on a system they already trust.

Build the Inefficiencies Too

This is the instruction that makes engineers wince, and I mean it literally.

Build the current process faithfully. Including the parts that are inefficient. Including the parts that are only inefficient because it’s paper and a spreadsheet — the redundant field, the number that gets copied twice, the column that exists so someone can eyeball a total.

Reproduce them.

Recognisability is what buys adoption. The person sitting down to your form on day one needs to see their own work looking back at them. Every silent improvement you slipped in is a small moment of “that’s not right.” Enough of those and they go back to the spreadsheet, and you never find out why.

So you keep a list instead. Every improvement you spot while building goes on it. None of them ship in version one.

Then, once they’re using it — once it’s theirs — you bring the list. And they choose. Not you.

They’ll pick better than you would, because half the things on your list are load-bearing for reasons that never appeared in any document. The silent correction someone makes to an illegible entry. The field they hand-compute because the person downstream expects it that way. The extra column they keep because the night shift uses it as a quick visual check. That tacit layer isn’t in the spreadsheet. A remake would have deleted it without ever knowing it existed.

The Asymmetry

Strip away the specifics and one thing remains.

Build the current process, and it’s validated continuously, by the person doing the job, every single day, starting immediately.

Build the remake, and it’s validated once, at the end, by a demo — at the exact moment when being wrong costs the most.

Same ambition. Same destination. Completely different risk.

The full system still gets built. Every module I’d designed still gets built. But now each one arrives with a user already attached, and each one is judged by someone who does the work rather than someone reviewing a document.

That’s not a smaller plan. It’s the same plan, sequenced so that being wrong stays cheap.

I spent five sprints proving the other way doesn’t work. You’re welcome to skip that part.

What’s the messiest process you’ve ever been tempted to redesign first — and what happened when you tried?