Product strategy
Prototype vs. Proof of Concept vs. MVP: What Should You Build First?
Choose the smallest artifact that answers your riskiest product question before you spend time building the wrong thing.
Prototype, proof of concept, and MVP are often treated as three names for an unfinished product. They are not. Each one exists to reduce a different kind of uncertainty, and choosing the wrong one can leave a team with plenty of activity but no useful answer.
The practical question is not which artifact sounds most advanced. It is what you need to learn next. A founder who is unsure whether an integration can work has a different problem from one who is unsure whether customers understand the workflow. Neither problem is solved by automatically building an MVP.
Three artifacts, three questions
The clearest way to understand prototype vs. MVP vs. proof of concept is to separate them by the question each is meant to answer.
A proof of concept asks: can this work? It tests a narrow technical or operational risk. A proof of concept might connect to an unfamiliar payment terminal, process a difficult data format, or confirm that an API can support a required workflow. It can be rough, incomplete, and invisible to customers. Its job is to produce evidence about feasibility, not to resemble a finished product.
A prototype asks: does this make sense? It explores how a product should behave or how a person will move through it. A prototype might be a paper sketch, a clickable design, or a coded interface with simulated data. It can look convincing while hiding most of the underlying implementation. Its purpose is to make an idea concrete enough to discuss, test, and revise cheaply.
An MVP asks: will this create value in real use? It is a small product that lets a specific user complete a meaningful job under real enough conditions for the team to learn from behavior. Unlike a prototype, an MVP has to work beyond a guided demonstration. It needs sufficient reliability, support, and data handling for the people invited to use it.
A proof of concept tests feasibility. A prototype tests understanding. An MVP tests value in use.
Calling every early build an MVP hides these distinctions. It also makes it harder to agree on what success looks like before the work begins.
Compare them side by side
The artifacts may share code or design work, but they have different audiences, standards, and stopping points.
Prototype vs. MVP vs. proof of concept
- Primary question: A proof of concept tests feasibility, a prototype tests an experience, and an MVP tests useful behavior.
- Typical audience: Technical stakeholders inspect a proof of concept; prospective users can react to a prototype; early customers use an MVP.
- Level of reality: A proof of concept may isolate one difficult component. A prototype can fake most systems. An MVP must complete one genuine workflow.
- Evidence of success: A proof of concept produces technical findings, a prototype produces usability feedback, and an MVP produces evidence from actual use.
- Expected lifespan: Proof-of-concept and prototype work is often disposable. An MVP may become the foundation of a product, although it should not be designed as if every early choice must last forever.
The amount of polish is not the deciding factor. A beautifully designed prototype is still a prototype if the important behavior is simulated. A plain internal tool can be an MVP if a real user depends on it to get a useful result.
Agree on the question and the evidence before choosing the format. Otherwise, stakeholders may judge a proof of concept as if it were production software or mistake positive prototype feedback for proof that customers will adopt the product.
When one should lead to another
Some products move from proof of concept to prototype to MVP, but that sequence is not a required product-development ceremony. Build only the artifacts needed to address material risks.
Imagine a scheduling product that must connect to a restrictive third-party system. The team could first build a proof of concept to confirm that appointments can be read and updated safely. It might then test a clickable prototype with reception staff to learn whether the proposed workflow matches how they resolve conflicts. Once those questions have credible answers, an MVP could support one type of appointment for a small group of real users.
A technically conventional product may not need a proof of concept at all. A familiar workflow may only need a few sketches before implementation. In other cases, the next useful experiment is an interview, a manual service, or a landing page rather than any of these three artifacts.
Start with the riskiest assumption, not the most visible deliverable. If the risk is feasibility, isolate it. If the risk is comprehension, make the experience testable. If the remaining risk is whether people will use the solution, plan a focused first version that can reach them.
Choose what to build first
Before assigning a team or software partner, write down the decision the next artifact must support.
A short selection checklist
- What assumption could make the product fail?
- Is that uncertainty technical, experiential, or commercial?
- Who needs to interact with the artifact?
- What observable result would answer the question?
- What can remain fake, manual, or out of scope?
If the answer is technical, build a proof of concept. If people need to understand or react to a proposed experience, build a prototype. If the experience is understood and you need evidence from real use, build an MVP—and protect it from unnecessary scope.
The right first artifact is the smallest one that changes what you know. Name the question clearly, gather the evidence, and let the result determine what deserves to be built next.