You Are Buying Verdicts, Not Prototypes: Price The Decision, Not The Build

Mostafa Dhouib·9 min read

You Are Buying Verdicts, Not Prototypes: Price The Decision, Not The Build

The short answer. A rapid prototype is not the deliverable. The deliverable is a decision: build this, or do not. That matters because the two ways of getting the decision wrong are not symmetric. A wrong no costs you the prototype plus a missed opportunity. A wrong yes costs you the full build, the integration, the migration, the team's attention for a quarter, and the slow unwinding afterwards, which together exceed the prototype cost by a large multiple. So the prototype's job is to be instrumentation pointed at whichever question would most change the answer. Scope it, price it and end it around producing the verdict.

The request almost never arrives in these terms. It arrives as a feature list. Can you build us a working version of this in a week, with these screens, reading from that device, so we can show it to the board.

We have learned to ask one question back before quoting. If this prototype works, what happens next? And if it does not, what happens instead?

If both answers are the same, the prototype is not a feasibility exercise. It is a demonstration, which is a legitimate thing to buy and a different thing to scope.

The asymmetry is the whole argument

Set the prototype's cost aside for a moment and look at the two errors.

A wrong no. You concluded something was infeasible when it was not. You have lost the prototype's cost and the opportunity. It is a real loss and it is bounded, because the idea can be revisited later when something changes.

A wrong keep. You concluded something was feasible when it was not, and the full build proceeded. You pay for the full engineering effort, the integrations, the data migration, the operational work of running it, the team's attention for a quarter or more, and then the much less visible cost of unwinding it: the commitments made to customers, the architecture built around an assumption that turned out to be false, the people who will spend the next year maintaining something nobody wants to admit was a mistake.

That second number exceeds the prototype's cost by a large multiple. Not a margin, a multiple. Which means the prototype's entire economic justification is its ability to prevent a wrong keep, and every design decision inside the prototype should follow from that.

The practical consequence is uncomfortable for a vendor. A prototype that ends in a no is a successful engagement. If the incentives are set up so that a no looks like a failure, you will reliably get a yes, and you will have paid for the most expensive possible outcome.

Instrumentation means aiming at the riskiest assumption

Once the prototype is instrumentation, the design question becomes narrow and answerable. Which assumption, if false, would change the decision most?

That assumption is rarely the one the feature list is about.

It is often not the feature. A team asking for a working version of a dashboard usually knows dashboards work. The thing they do not know is whether the data arriving from the device is good enough to drive one, at the rate they need, with the gaps and duplicates real conditions produce.

It is often the boundary. Whether a device can be read at all, in the field, by a client application running on hardware you do not control. Whether the third party's interface behaves as documented under load. Whether the data that exists in a sample file exists the same way in production.

It is often not technical. Whether a regulator, a review process or a platform's rules permit the thing at all. These can kill a project outright and no amount of working code answers them.

So the first day of a prototype engagement is spent listing assumptions and ranking them by how much the decision would move if each turned out false. The top two or three get built against. Everything else gets faked, stubbed, or hardcoded, deliberately and visibly.

This is why a good feasibility prototype often looks worse than clients expect. If the risky assumption is the device link, the prototype should have an ugly interface and an excellent instrumented data path. A pretty interface over a faked data path answers nothing and is more convincing, which makes it actively harmful.

Write the verdict criteria before you write code

A verdict needs a threshold decided in advance, because a threshold decided afterwards is just a description of whatever happened.

We write a short document on day one with three things in it.

The question, in one sentence. Not "evaluate feasibility of the telemetry platform." Something like: can we read the required fields from the device, at the required rate, on the client's own runtime, without a change to the device firmware.

What a yes looks like, numerically where possible. A rate, a success percentage, a latency, an error class that must not appear. The numbers come from the client's actual requirement rather than from what seems achievable, which is the common corruption.

What a no looks like, and what happens then. This is the part teams resist writing, and it is the part that makes the verdict credible. If the answer is no, is there an alternative path worth a second week, or does the idea stop? Deciding that while nobody knows the answer yet is far easier than deciding it afterwards.

Signed by whoever will make the build decision. If that person is not available to agree the criteria, they will not accept the verdict either.

What this changes about scoping and pricing

Scope the question, not the feature set. The statement of work should name the assumptions being tested and the thresholds. Feature lists invite scope expansion, because every additional screen sounds small and none of them move the verdict.

Price for the decision, not the days. The value delivered is the avoidance of a wrong keep, which is worth a large multiple of the prototype. That justifies spending the first day on front-loading risk rather than on building, which a day-rate framing makes look like waste.

Make a no a deliverable. State explicitly that a documented no, with the evidence and the thresholds it failed, satisfies the engagement in full. Put it in writing. It is the single change that most improves the quality of the answer, because it removes the pressure to produce a working demonstration regardless of what was learned.

End on the verdict, not on the demonstration. The closing artefact is a short document: the question, the criteria, what was measured, the verdict, and the evidence behind it. The running code is an appendix. Teams keep the code and lose the document, which is the wrong way round, because the code will be thrown away and the verdict is what the next decision rests on.

The honest limit

The asymmetry argument assumes a wrong keep leads to a full build. Sometimes it does not, because a second gate catches it later and the loss is smaller than described. If your organisation genuinely has a strong later gate, the multiple shrinks and the case for spending heavily on an early verdict weakens. In our experience those gates are weaker than teams believe, because by the time a project reaches one it has sponsors, and sponsors are expensive to contradict. But we cannot assert that about your organisation.

We also have no defensible figure for the multiple. It plainly exceeds the prototype cost by a lot, and the components are real and enumerable, but anyone presenting a precise ratio has estimated it. What can be done properly is estimating it for one specific decision, with your own build costs, before you commit.

And the honest limit on verdicts themselves: a verdict is only as good as the assumption ranking that preceded it. We have tested the top two risks correctly, returned a confident yes, and been wrong because the risk that actually mattered was ranked fourth. A prototype narrows uncertainty around the questions you thought to ask. It does nothing about the ones you did not.

FAQ

What should a rapid prototype actually deliver? A decision, with the evidence behind it. Build this or do not, measured against criteria agreed before any code was written. The running software is an appendix to that, and it will usually be thrown away. Teams that keep the code and lose the decision document have kept the disposable half of the engagement.

Why does a wrong yes cost so much more than a wrong no? A wrong no costs the prototype and a bounded missed opportunity, and the idea can be revisited. A wrong yes triggers the full build, the integrations, the migration, a quarter of the team's attention, and the slow cost of unwinding commitments made on a false assumption. Those together exceed the prototype's cost by a large multiple, which is the whole economic case for doing the prototype properly.

Why does a good feasibility prototype look unfinished? Because effort goes to the riskiest assumption and everything else is deliberately faked. If the real question is whether a device can be read reliably on the client's own runtime, the right prototype has an ugly interface and a heavily instrumented data path. A polished interface over a stubbed data path answers nothing while being more persuasive, which makes it worse than useless.

How do you stop a prototype from always concluding yes? Write the pass and fail criteria on day one, taken from the actual requirement rather than from what looks achievable, and get them agreed by whoever will make the build decision. Then state in the engagement that a documented no satisfies the contract in full. Without that, the incentive to produce a working demonstration will shape what gets measured.

What should go in the final document? The question in one sentence, the criteria for yes and for no, what was measured and how, the verdict, and the evidence. Keep it short enough that the decision maker reads all of it. The code, the test harness and the raw measurements are attachments, since the verdict is what the next decision will actually rest on.

Is a demonstration ever the right thing to buy? Yes, and it is worth being honest about which one you want. If the technical question is already settled and you need something to show a board or a customer, that is a demonstration, and it should be scoped for persuasiveness. The failure is buying a demonstration while believing you bought a verdict, then treating the demonstration as evidence of feasibility.