Prototype vs MVP: which should you build first?
Compare a prototype, proof of concept, and MVP. Choose the deliverable that answers your next product question before paying for a full app build.
By Chase Poirier · Updated · 8 min readA clickable demo and a working customer product answer different questions. I would choose between a prototype, proof of concept, and MVP by naming the uncertainty first. This comparison helps you buy the next useful test without assuming every project needs all three.
Choose the next question
- Prototype: experience
- PoC: feasibility
- MVP: real use
Choose the question before the deliverable
If you cannot picture the customer journey, an interface prototype may help. If the uncertainty is whether a required system can provide the right data, a targeted technical test may be more useful. If customers are ready to use the product, a visual demo alone will leave delivery gaps.
| Deliverable | Useful for | Does not establish |
|---|---|---|
| Prototype | Exploring screens, interactions, and customer understanding | Reliable production behavior or willingness to pay. |
| Proof of concept | Testing a particular technical assumption | That the complete product is ready to launch. |
| MVP or first release | Delivering a bounded customer result in actual use | Sustainable demand, retention, or profitability. |
Follow the same product through each kind of test
Consider an illustrative assessment business. Clients send spreadsheet answers to an expert, who reviews them and returns recommendations. The founder wants a self-service product with automated reports. Several uncertainties sit inside that idea, and each needs different evidence.
A clickable prototype could show whether a client understands the questions and can find the result. A technical proof of concept could test whether the existing scoring method can process representative answers. An MVP could let a real client submit an assessment, have the founder review it, and receive an approved report.
These are possible next steps, not a required sequence. If the scoring method already works and customers understand the workflow, a separate prototype may add little. If the result depends on an untested external data source, designing every screen before checking that dependency may create avoidable rework.
| Deliverable | What the customer can do | What the founder learns |
|---|---|---|
| Clickable prototype | Move through sample questions and a prepared report | Whether the proposed flow and language make sense in the test. |
| Technical proof of concept | Usually nothing in a finished customer interface; the builder tests sample inputs | Whether a specific operation works under stated conditions. |
| MVP with expert review | Submit real answers and retrieve a reviewed report through their account | How the bounded workflow performs in actual use, including manual effort. |
Use a prototype to review the customer journey
A prototype can be sketches, linked screens, or working code. Ask what is real and what is simulated. A payment button might open a sample success screen without processing a payment; a report might use prepared data.
Those shortcuts can be appropriate when the purpose is reviewing the journey. They become a problem if everyone assumes the prototype is almost ready for customers. Record the missing production work before using it as the basis for an estimate.
Give a prototype test a real task
Instead of asking whether someone likes the design, ask them to imagine preparing an assessment for a new client. Let them find the invitation, start the questions, and work out where the completed report will appear. Watch where they hesitate and record what they expected.
If you explain every button before the participant uses it, the test may tell you whether they can follow your instructions rather than whether the interface is understandable. Keep the task specific and distinguish observed behavior from suggestions about features.
After the session, write the decision: change the wording, remove a step, or test a different workflow. A prototype is useful when it changes what you would otherwise build. A polished presentation can help explain an idea, but presentation quality alone does not establish that customers can use it unaided.
A proof of concept should have a stopping condition
Name the assumption, the test conditions, and what result would justify the next step. For example, can the app retrieve the specific records needed from a vendor system using available permissions?
A successful test resolves that question within its tested limits. It does not remove the need for integration error handling, access controls, and testing in the complete product. Ask what remains after the experiment.
A passing demo needs a written boundary
For a scoring test, choose inputs that resemble the intended work, including incomplete answers and unusual combinations. State the expected output and who is qualified to judge it. A sample that was selected because it produces a good answer gives you less evidence than a representative set with known difficult cases.
If the product uses AI to draft recommendations, decide how those drafts will be checked and what happens when they are unsuitable. Record which examples were tried and the limits of the conclusion. A convincing answer to one sample does not justify automatic delivery to customers.
Before funding the test, agree what the finding will enable: proceed with human review, change the method, or remove the operation from the first release. Avoid leaving the experiment open-ended because there is always another prompt, model, or integration setting to try.
An MVP still needs a complete customer workflow
Minimum does not mean that critical steps are missing. Customers need an understandable path to the agreed result, appropriate protection for their information, and a way to get help. Which responsibilities sit in software and which remain manual should be clear.
Imagine an expert-led assessment product. The first release might let a customer submit information and receive a founder-reviewed result. Automated recommendations could wait. This example illustrates a possible first release; the scope would need to be agreed for an actual project.
Make the remaining production work visible
A prototype might store everything in a browser, simulate payment, and show every participant the same report. A product used by customers needs deliberate decisions about saved data, user access, billing, support, and recovery. Which requirements apply depends on the actual service and its risks.
Ask the provider to classify each working part before quoting the next stage. Reusable code may still need testing or changes. A simulated action needs an implementation. A missing business decision needs your input. That inventory is more useful than describing the prototype as a percentage complete.
For the assessment example, a minimum usable release could retain manual expert review while implementing reliable submission and private result access. Automatic recommendations can wait if the service promise allows that. Protecting customer information and getting the result to the right person belong in the first release.
| Prototype behavior | Production decision still needed |
|---|---|
| Sample user opens all screens | Define accounts, roles, and which records each person can read. |
| Report appears instantly | Define how it is produced, reviewed, published, and corrected. |
| Payment screen always succeeds | Define the actual buying arrangement and failure handling. |
| A successful demo is the only test | Agree acceptance checks, operating instructions, and supported environments. |
Match the test to the customer commitment
If an industry peer has agreed only to react to screens, a prototype may help you discuss the workflow. If a customer has agreed to use the product with real information, find out which safeguards, setup steps, and support they need before choosing the release scope.
A prototype review, an active pilot, and a paid customer establish different things. Record what the person actually agreed to do. You can then decide whether the next investment should answer a design question, a feasibility question, or a question that needs real product use.
When you can skip a separate prototype
A familiar workflow with known technology may go directly into a scoped first release. An uncertain integration may need a proof of concept before interface work. Ask which question each proposed step answers before paying for the sequence.
Ask each provider what the proposed deliverable resolves, what you can do with it, and what further work would be required before customers use it. Then compare the next decision it enables.
Common questions
What is the difference between a prototype and an MVP?
A prototype shows or tests how a product could work; parts may be simulated. An MVP is a limited product customers can actually use to complete the intended workflow. Confirm what is real in either deliverable. A prototype with prepared data can support a design decision while still requiring substantial production work before customer use.
Do I need a prototype before an MVP?
Only if it resolves a meaningful uncertainty. A prototype can help people review an unfamiliar interaction before development. A familiar workflow may be scoped directly into a first release. If the main risk is whether a vendor integration works, a focused technical test may be more useful than designing a full set of screens first.
Can a prototype be turned into a real app?
Sometimes parts can be reused, but that depends on how it was built and tested. Ask which parts are simulated and which meet production requirements. Customer data handling, access controls, error recovery, and support may still need work. Request a separate assessment of the remaining build instead of treating the prototype as a nearly finished application.
Choose the customer result to test
Write down what you need to learn next and the least work that would answer it. If customers are ready to try a working product, define the first release around the result they need.
Scope a useful first release