You know what you want. You have described it clearly. Somebody now suggests spending three weeks and several thousand pounds on screens that do not work, before building the ones that do, and it sounds like a way of billing for thinking.
The reason to prototype before building software is arithmetic rather than philosophy: being wrong on paper costs days, and being wrong in code costs months. The question is only whether you are likely to be wrong, and there are cases where you are not.
What a prototype is, precisely
Real screens, arranged in a real flow, that you can click through on a phone or laptop. Nothing behind them. No database, no logic, no saving. It looks finished and it does nothing.
That combination is the point. It is convincing enough that people react to it as though it were software, and cheap enough that you can throw the whole thing away on a Tuesday and rebuild it differently by Thursday.
What it can tell you, and what it cannot
| A prototype answers | A prototype cannot answer |
|---|---|
| Can people work out what to do without being told? | Will it be fast enough with real data? |
| Is anything obviously missing from this flow? | Will the integration actually work? |
| Do the words make sense to someone outside the business? | How much will it cost to run? |
| Are we all imagining the same product? | Is the underlying approach technically sound? |
| Which steps do people hesitate at? | Will people keep using it after the novelty? |
| Is this worth building at all? | Whether they would pay for it, reliably. |
The right-hand column matters. A prototype that is used to answer a technical or commercial question gives a confident answer to something it cannot know, which is worse than not asking.
The disagreement it surfaces
The most valuable thing a prototype does is not user testing. It is discovering that the people who agreed on the written specification were picturing different products.
This happens on almost every project of any size. Two people read customers can manage their bookings and one imagines a list with a cancel button while the other imagines rescheduling, part-cancellation and a refund policy. Both sign off the document honestly. The gap surfaces at the first demo of working software, eight weeks in, and closing it means unpicking decisions that everything since has been built on.
On a prototype, that same disagreement surfaces in a meeting on day nine and is resolved by moving rectangles. Same discovery, two orders of magnitude cheaper.
The rule that keeps it cheap
A prototype must be genuinely throwaway. The moment anyone tries to keep it, it stops working as a prototype and becomes a slow, expensive first version.
- Nothing in it should be reusable, and that is the feature. If it were built to be kept, you would hesitate before throwing away a bad idea, which is precisely the hesitation you paid to remove.
- Expect three versions, not one. If a prototype survives contact with real people unchanged, either it was not shown to anyone honest or it was not a real test.
- Do not let it become the specification by accident. The prototype answers questions; the answers become the specification. A prototype handed to developers with no written decisions attached invites everyone to interpret it again.
- Timebox it. Two to three weeks. A prototype that runs for two months has stopped being cheap and has started being a project.
What prototyping costs against building the wrong software
Illustratively $4,000 to $12,000 over two to three weeks for a first version's worth of screens, or less for a single flow.
Set against that: a fortnight of rework mid-build on a modest project costs about the same, and a fundamental change of direction in month three costs several times more, because everything built since the wrong decision has to be unpicked. On projects with genuine unknowns, we have never regretted the prototype and have regularly regretted skipping it. That is not a promise it always pays, it is what we have seen.
The other saving is on the quote itself. Suppliers price uncertainty, so a project described by a tested prototype attracts less contingency than the same project described in prose. How to write a software brief covers the written half, and a prototype is frequently a better specification than any document.
How to test one properly
- Find five people who will actually use it. Not colleagues who know the plan. Five is enough to see every pattern that matters.
- Give them a task, not a tour. Book an appointment for next Tuesday, not let me show you the booking screen. The moment you explain, the test is over.
- Then stay quiet. The urge to help is overwhelming and the silence is the finding. Write down where they hesitate.
- Ask what they expected to happen at each point they paused, which tells you more than asking what they thought of it.
- Change it between sessions. Testing the same broken flow five times learns one thing; fixing it after the second learns three.
- Write down the decisions, not just the observations, because the decisions are what the build needs.
The four kinds, and which you need
Prototype covers several quite different exercises at different prices, and buying the wrong one is a common way to waste the budget.
| Kind | What it is | Answers |
|---|---|---|
| Sketches | Boxes and arrows, an hour with a pen, no visual design at all. | Does the flow make sense to us? Free, fast, and enough surprisingly often. |
| Clickable screens | Designed screens linked into a flow you can tap through. The usual meaning. | Can a real person complete the task, and does everyone agree what we are building? |
| A technical spike | Throwaway code proving one risky thing works. No interface worth looking at. | Will this integration work, is this fast enough, is this approach sound? The questions a clickable prototype cannot touch. |
| A concierge test | Doing the job by hand for a few customers, with no software at all. | Does anyone actually want this, and what are the real rules? The cheapest and least used of the four. |
The last row deserves more attention than it gets. If your uncertainty is whether people want the thing, two weeks of doing it manually teaches you more than any amount of design.
Most projects with real unknowns want the second and the third, and they are usually run at the same time by different people. If a supplier proposes only the second when your risk is technical, they have chosen the exercise they enjoy rather than the one you need.
When to skip it
- The thing is small and well understood. A form, a page, a report. Just build it, and if it is wrong, change it in an afternoon.
- You are copying something that exists, including your own current process, closely enough that the interface is not in question.
- The risk is technical rather than human. If the doubt is whether the integration will work or whether it will be fast enough, prototype the technical part instead, which is a different exercise.
- The build is cheap enough to be the prototype. Sometimes two weeks of building answers the question better than two weeks of screens, and that is a legitimate choice.
- It is genuinely disposable software with a short life and few users. Ceremony costs more than the mistake would.
Not for you if
The test for whether you need one: write down the decision you are least sure about. If it is a question about people, prototype it. If it is a question about systems, build a technical spike instead. If you cannot name a decision you are unsure about, you probably do not need either, and you should go and build the thing.