Product investment decision
MVP vs prototype: which should you build first?
Use a prototype to test an uncertain idea. Use an MVP when you need a real, bounded product experience to learn from actual use. The distinction is the evidence you need, not how polished the screen looks.
Choose by the decision you need to make
A prototype represents or explores a proposed experience. It may be a sketch, clickable interface or limited technical experiment. An MVP is a deliberately small product release that delivers an actual outcome for an agreed user group. Neither term tells you its quality simply by naming it.
Use a prototype when you need to find out whether people understand the journey, whether a proposed interaction helps or whether a technical assumption is feasible. Use an MVP when those answers are sufficient to justify serving real users and you need evidence from the resulting use.
The GOV.UK prototyping guidance supports testing alternative designs before committing to production implementation. It is a useful reference, not a requirement to adopt government delivery terminology.
Compare the responsibilities, not the appearance
| Question | Prototype | MVP |
|---|---|---|
| Primary purpose | Test a specific assumption | Deliver a core outcome and learn from use |
| Data | Often synthetic or controlled for research | Appropriate handling of the data needed for real use |
| Integrations | May be simulated unless integration is the test | Must support the promised outcome, or have an explicit operating alternative |
| Failure handling | Limited to the research context | Must cover failures that matter to users and operators |
| Learning signal | Observed understanding, behaviour or feasibility | Actual completion, repeat use and operating effort |
| Ownership after the test | Can be discarded or reworked | Needs support and a deliberate next-release decision |
A high-fidelity prototype can look more complete than an early MVP. Ask what is real behind the interface before interpreting a demonstration as delivery evidence.
Keep a prototype honest about what it proves
Write the question before building the prototype. For example: can a customer distinguish an enquiry from a confirmed booking? Test that interaction with suitable participants and observe where their understanding differs from the team’s intention.
Use safe sample information and explain what is simulated. If every participant can navigate the screens, you have evidence about the interaction, not proof that the business can fulfil bookings or that customers will pay.
A technical proof of concept is a related experiment with a narrower feasibility question, such as whether an approved API exposes the required data. It can sit beside a design prototype. Neither automatically establishes a complete product journey.
Keep an MVP narrow without making it misleading
A viable release must make good on its defined promise. If it says a request was submitted, the responsible team must be able to find and handle it. If it shows a confirmed result, that state must reflect the actual business process.
Manual review can be part of the first release if it is deliberate, staffed and compatible with the learning goal. Manual activity should not be described as automation. Restricting the initial audience is also a valid scope decision when support and capacity are agreed.
Use the MVP service page to define the first complete outcome, then discuss the budget and delivery forecast for that boundary.
Follow one idea through two different tests
Hypothetical example: a business wants to offer an online request service. It first tests a prototype to find out whether customers understand the information required and the difference between “received” and “approved”.
After resolving that uncertainty, the MVP accepts real requests for one service category. Staff review them, send a response and record the result. The business measures completion, unresolved cases and operating effort.
The prototype tests comprehension. The MVP tests whether the bounded service works in practice. If the prototype reveals a fundamental mismatch, changing or stopping the idea may be the most useful result. Building more software is not always the next step.
Do not promote prototype code without review
Some prototype work can inform production implementation, but code reuse is a separate engineering decision. Review data handling, access controls, dependencies, deployment and tests before allowing real users to rely on it. Shortcuts acceptable in a research setting may not be acceptable in a product.
AI tools can make an interface quicker to explore. They do not change which assumptions it has tested. Treat generated code and plausible sample outputs as material to examine, not evidence of a complete service. LCR's AI-built prototype review explains the production questions considered before agreeing the next release.
Agree a decision after each experiment: stop, revise, investigate a specific risk or build the first viable release. If the chosen route is a Laravel application, use the Laravel MVP guide to discuss what should be implemented and verified.
Sources and review date
Sources reviewed on 6 September 2026 and linked beside the guidance they support. Examples are hypothetical. This page provides planning guidance, not a project quote, fixed delivery promise or guarantee of commercial results. Confirm scope and responsibilities with the delivery team.
Questions
Frequently asked questions
Can a prototype become an MVP?
It can inform the MVP, and some code may be reusable after review. A realistic-looking prototype does not automatically meet the operating, security and reliability needs of real use.
Is a proof of concept the same as a prototype?
A proof of concept usually tests technical feasibility. A design prototype tests a proposed experience. Name the question being tested rather than relying on the label alone.
Can a small MVP contain manual operations?
Yes, if the manual steps are explicit, supportable and compatible with the outcome being tested. Do not present them as automated capabilities.
Plan the first useful release
Bring the user problem and the outcome you need.
Discuss the core journey, the systems it depends on and the evidence needed before launch.