Prototype, MVP, and full build are not three price levels for the same thing.
They are different product decisions. Each should answer a different question, carry a different operational burden, and create a different kind of evidence.
Teams get into trouble when they choose the label before identifying what they need to learn. A prototype is called an MVP because it has working screens. An MVP is treated like a production platform because a customer can log in. A full build begins before the buyer, workflow, and system boundaries are stable.
Start with the decision you need to make next
The useful question is not “How much product can we build?” It is “What uncertainty is blocking the next responsible decision?”
Choose a prototype when interaction is the uncertainty
A prototype is useful when you need to demonstrate a workflow, test navigation, align stakeholders, or make an abstract idea concrete. It can be coded or visual, but it is not automatically a reliable operational system.
A prototype should help answer questions such as:
- Can the intended user understand the workflow?
- Are the main steps and decisions represented correctly?
- Does the concept communicate enough value to justify deeper validation?
- Which assumptions become visible once people can interact with the idea?
It should not quietly inherit production expectations around security, data migration, uptime, auditability, integrations, or support unless those were explicitly part of the scope.
Choose an MVP when real use is the uncertainty
An MVP is the smallest product that can support a real learning cycle with an actual user or operating context. “Minimum” should describe disciplined scope, not missing reliability around the core promise.
A credible MVP needs enough structure to answer:
- Will the intended user complete the core workflow?
- Does the product solve a problem that matters enough to continue?
- Which product and operational assumptions fail under real use?
- What support, data, permissions, and recovery work appears once the product leaves the demo?
The MVP may still exclude broad automation, advanced reporting, multiple integrations, and secondary user journeys. But the core path should be honest about the environment in which it will be used.
Choose an architecture phase when technical risk is already material
Sometimes the product opportunity is sufficiently clear, but the first implementation decision carries meaningful backend, data, integration, security, multi-tenant, payment, or system-of-record risk. In that case, jumping directly into an MVP can make the most expensive decisions implicitly.
An Architecture Sprint should resolve boundaries, tradeoffs, major failure modes, and sequencing before delivery. It is not a decorative diagram exercise and does not replace product validation.
Choose a fuller build when the operating commitment is clear
A broader build is justified when the buyer and problem are supported, the core workflow is understood, important technical risks are bounded, and the organization is ready to operate what it is funding.
That readiness includes more than feature requirements:
- ownership for product decisions and support;
- a data and permission model;
- deployment, observability, and recovery expectations;
- a plan for integrations and migration;
- capacity to learn from real usage and change the roadmap.
A simple selection model
- If you need to make the idea understandable, start with a prototype.
- If you need to learn from real use, scope an MVP around one core promise.
- If technical decisions can create material long-term risk, resolve architecture first.
- If product, technical, and operating commitments are all clear, plan the fuller build in phases.
The right first step is the one that produces the evidence needed for the next decision without pretending uncertainty has already been removed.
If you have domain insight but need to decide what should be built first, explore the SaaS / MVP path before committing to a larger build.