A prototype answers one question
The most useful thing you can do before building anything is finish this sentence: we are building this to find out whether…. Whether users will complete the flow without help. Whether the data is clean enough to be worth showing. Whether the board will fund the full thing once they can click it. Whether the technical approach holds at realistic volume.
Prototypes without that sentence expand until the budget stops them. Prototypes with it end early and cheaply, because you can tell when you have the answer.
Prototype the risk, not the product
Every project has one part nobody is sure about, and a long tail of parts everyone has built a hundred times. Login is not risky. Settings pages are not risky. The risky part is usually the thing that makes the product different — the matching logic, the live data feed, the 3D scene running acceptably on a mid-range laptop, the moment a user has to trust the output.
Spend the whole budget on that. Fake everything else without apology: hard-code the user, skip the admin screens, stub the payment. If the risky part fails, none of the surrounding work would have mattered anyway.
Use the fidelity dial deliberately
Fidelity is not one setting. It is three, and they should rarely be turned up together.
- Visual fidelity. How finished it looks. Turn this up when the audience is external — investors, clients, a public demo — because rough visuals get read as a rough idea.
- Functional fidelity. How much actually works. Turn this up when the question is whether people can use it.
- Data fidelity. How real the content is. Turn this up when the question is whether the idea survives your actual mess.
A clickable design with no working code answers usability questions cheaply. A rough-looking build against real data answers feasibility questions cheaply. Building something that is polished, functional and fully wired is not a prototype — it is version one, priced as a prototype.
Choose one journey and follow it end to end
The strongest prototype covers one path completely rather than five paths partially. Pick the journey that carries the value: the enquiry that becomes a booking, the site walk that becomes a report, the upload that becomes a dashboard.
A user who can go start to finish tells you something real. A user who hits “not built yet” three screens in tells you nothing, and spends the rest of the session imagining the software rather than reacting to it.
Write the exit criteria before you start
Agree in advance what would count as a yes, a no and a not-yet. Otherwise the review meeting becomes a discussion of colours.
- Who is going to use it, by name, and when is it in front of them?
- What are we watching — can they finish, do they trust it, do they come back?
- What result would make us stop, and are we honestly willing to stop?
- Who signs off, and what are they being asked to approve?
That third question is the one people skip. A prototype that cannot fail is a very expensive way of confirming what you already believed.
Finish with a plan, not just a demo
The deliverable at the end of a good prototype is not the prototype. It is a decision plus a build plan: what to keep, what to cut, what data has to be sorted out first, what the production version should cost, and where the remaining unknowns are.
Half of what a prototype teaches is negative — the feature everyone argued about that nobody touched, the screen that turned out to be the whole product. Write both halves down. That document is usually worth more than the code, and it is the thing that stops the same argument being had again in month four.
If the thing you are prototyping is a SaaS platform specifically, we go deeper on that path in prototyping SaaS platforms before the full build.
Common questions
What is the difference between a prototype and an MVP?
A prototype exists to answer a question and can be thrown away. An MVP is the smallest version you would be happy for real customers to use and pay for, so it has to be built to survive. Confusing the two is how a two-week demo turns into a six-month rebuild.
How long should a prototype take?
Two to six weeks for most business software. If a proposal runs longer than that before anything is testable, the scope has quietly become a first version rather than a prototype, and the cost and risk profile change with it.
How much does a prototype cost?
A proof of concept typically starts from £2,800 and a rapid MVP from £2,995. If you are not yet sure the idea is worth prototyping, a £495 idea validation session is the cheaper way to find out.
Should a prototype use real data?
Wherever it is safe to. Realistic data is what exposes the awkward cases — the client with three addresses, the job that spans two months, the field everyone leaves blank. Perfect demo data hides exactly the problems a prototype exists to find.
What should a prototype produce at the end?
Three things: a decision, a list of what was wrong about the original assumption, and a build plan with a number attached. A demo video on its own is not a result.
Related guides
- Prototype SaaS platforms before the full build — the SaaS-specific version of this
- Website, app, dashboard or SaaS? — getting the category right first
- Rescuing a vibe-coded app before launch — what to do when the prototype went too far
- Pricing — proof of concept and rapid MVP bands