Why Prototypes Save Money on Software Projects

Software projects go wrong in a predictable way. Everyone agrees the requirements and signs, development happens, and at the demo somebody says: "oh, but what about when the order gets split across two shipments?"

Hearing that in month four is expensive. In week two it costs nothing. Running prototype checkpoints is all about hearing it earlier.

Why specifications miss it

People can’t reliably judge a description of software. Put the software in front of them and they can.

Hand somebody a twelve-page specification and they’ll read it, nod at the parts they understand, skim the rest, and approve it. A document is an abstraction, and checking it against a process you do from muscle memory is hard even for careful people.

Hand the same person a screen and ask them to do Tuesday’s work on it. Within ten minutes you’ll hear "where do I put the PO number?" Nobody wrote the PO number into the spec because everybody knew about it. It was so obvious nobody saw it.

People forget to mention the requirements everyone already knows.

How fast the cost climbs

During blueprinting, a change means a conversation and an edited diagram. Once the data model is built, the same change touches the schema, the code that reads it, the screens, the reports and the migration plan. It costs an order of magnitude more, and every week of build in between widens the gap.

So a rough estimate of the right thing is worth more than a very accurate estimate of the wrong thing. Estimate precisely from a spec with a wrong assumption in it and you get a confident number for software nobody wanted.

What a checkpoint looks like

The people who do the work need something they can operate themselves. A slide deck or a demo they sit and watch won’t do it.

1. Clickable screens, early. These come before the data model is final. There’s no real data and no working logic yet, just the flow, so people can walk through their actual task.
2. A working slice, next. One complete path, end to end, with real data. Keep it narrow.
3. Their data, in their hands. Users sit at their own desks doing real work, which tells you far more than a scripted walkthrough in a meeting room.
4. The awkward cases, deliberately. The split order. The customer with two addresses. The job that got cancelled after invoicing. Ask for the weird ones on purpose, because that’s where the assumptions break.

Who has to be in the room

The people who do the work every day need to be there, along with the manager who commissioned the project. The manager knows how the process is supposed to run. The person doing it knows the six exceptions that come up every week and have never been written down.

Most of the surprises live in that gap. It’s also why the review phase on our projects sits with the people doing the job instead of following the org chart.

What "approved" should mean

"This looks good" is politeness, and politeness at a checkpoint gets paid for later.

Approval should mean somebody did a real task on it and the task worked. If they couldn’t finish the task, that’s the finding, and finding it now is cheap. When nobody criticised a checkpoint, usually nobody used it.

The trade-off

Prototypes cost time up front and push the start of real development back by weeks. That’s a real cost, and it feels like delay, especially to whoever is paying.

In exchange, discovery moves to the beginning of the project, where it’s a conversation. Left to the end, it shows up as a change order and a slipped date. You’ll find these things out either way, and prototypes let you pick when.

That’s why our process puts a prototype checkpoint between blueprint and build, with no single big reveal at the end. It’s also why the estimate we give after blueprinting is worth more than one we could give before it.