Prototype, MVP, and full development are not three sizes of the same product. Each supports a different decision. Choosing the right one begins with what you need to learn or operate next.
It is normal to be unsure how much to build first
The terms are used inconsistently. One proposal may call a clickable demo an MVP, while another uses MVP for a live paid service. Align the expected users, data, reliability, and operating responsibility instead of relying on the label.
The short answer
- A prototype tests a workflow, interaction, or technical assumption.
- An MVP delivers the minimum live value to real users and supports learning through operation.
- Full development targets an agreed production scope with the reliability and controls needed for ongoing use.
Ask what decision the deliverable enables and what it is explicitly not safe or ready to do.
Prototype, MVP, and full development compared
A prototype may use sample data, simulated integrations, and limited error handling. It should have a test plan and a non-production boundary.
An MVP handles real users and therefore needs appropriate authentication, privacy, security, monitoring, support, and data recovery even when its feature set is small.
Full development adds the broader workflows, roles, integrations, operational controls, and quality level justified by proven needs. It may still be delivered in stages.
When a prototype is appropriate
Choose it when people need to see a flow before agreeing, when usability is uncertain, when the admin process is unclear, or when an integration assumption could change scope. Define the participants and evidence before building.
When an MVP is appropriate
Choose an MVP when a small group can receive real value from one complete workflow and the organization is ready to operate and support it. The MVP must be safe for its actual data and users. “Minimum” does not excuse missing security or unclear ownership.
When full development is appropriate
Proceed when the core workflow is understood, broader use is justified, mandatory integrations and controls are known, and the organization can fund launch and ongoing operation. Confirm acceptance criteria, migration, monitoring, maintenance, and exit arrangements.
Separate the options by evidence, not build volume
Use a prototype to answer “Can users understand and complete this flow?” Use an MVP to answer “Will real users adopt this value, and can we operate it?” Use production expansion to answer “How do we serve the validated need reliably at the required scale?”
Practical notes before a consultation
Say what you want to validate rather than “build an MVP cheaply.” State whether real customers, personal data, payments, or business-critical operation are involved. List temporary manual steps and the event that would justify automating them.
How-much-to-build checklist
- [ ] The next decision is explicit.
- [ ] Test users and data are identified.
- [ ] Production and non-production boundaries are clear.
- [ ] One end-to-end value flow is selected.
- [ ] Security and privacy match actual use.
- [ ] Manual operation and ownership are documented.
- [ ] Success and stop criteria are agreed.
- [ ] The next investment is conditional on evidence.
Your next step
Complete this sentence: “After the first build, we need enough evidence to decide whether ______.” Then ask which deliverable produces that evidence with the least avoidable risk.
Further reading
Use usability research guidance for prototypes, product analytics and operational metrics for MVPs, and authoritative security, accessibility, privacy, and platform documentation for anything used in production.