Prototypes Save More Money Than Good Estimates Do

A software project goes wrong in a predictable way. The requirements are agreed, everybody signs, development happens, and at the demo somebody says: "oh — but what about when the order gets split across two shipments?"

That sentence, in month four, is expensive. The same sentence in week two costs nothing. The entire discipline of running prototype checkpoints is about moving that sentence earlier.

Why specifications do not catch it

People cannot reliably evaluate a description of software. They can evaluate software.

Hand somebody a twelve-page specification and they will read it, nod at the parts they understand, skim the parts they do not, and approve it. Not out of carelessness — a document is an abstraction, and checking an abstraction against a process you perform by muscle memory is genuinely hard.

Hand the same person a screen and ask them to do Tuesday’s work on it, and within ten minutes: "where do I put the PO number?" Nobody wrote the PO number in the spec because everybody knew about the PO number. It is so obvious it was invisible.

The requirements people forget are the ones they could not imagine anybody not knowing.

The cost curve is not gentle

A change during blueprinting is a conversation and an edited diagram. The same change after the data model is built touches the schema, the code that reads it, the screens, the reports, and the migration plan. It is not twice as expensive, it is an order of magnitude, and every week of build between the two widens the gap.

This is why a very accurate estimate of the wrong thing is worth less than a rough estimate of the right thing. Estimating precisely from a specification containing a wrong assumption produces a confident number for software nobody wanted.

What a checkpoint looks like

Not a slide deck and not a demo you watch. Something the people who do the work can operate themselves.

1. Clickable screens, early. Before the data model is final. No real data, no working logic — just the flow, so people can walk their actual task.
2. A working slice, next. One complete path end to end with real data. Narrow and real beats broad and fake.
3. Their data, in their hands. Users at their own desks doing real work, not 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 — they are where the assumptions break.

Who has to be in the room

The people who do the work daily, not only the manager who commissioned the project. This is not a slight on managers — the manager knows how the process is supposed to run, and the person doing it knows the six exceptions that come up every week and have never been written down anywhere.

That gap is where most of the surprises live. It is also why the review phase on our projects sits with the people doing the job rather than with the org chart.

What "approved" should mean

Not "this looks good." That is politeness, and politeness at a checkpoint is a cost you pay later.

Approval should mean somebody performed a real task on it and it worked. If they could not complete the task, that is the finding, and it is a cheap finding. A checkpoint that nobody criticised is usually a checkpoint nobody actually used.

The trade-off, honestly

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

The trade is that discovery moves from the end of the project — where it arrives as a change order and a slipped date — to the beginning, where it is a conversation. You do not avoid finding out. You choose when.

It is the reason our process has a prototype checkpoint between blueprint and build rather than a single reveal at the end, and it is why the estimate we give after blueprinting is worth more than the one we could give before it.