Defining a Prototype
A prototype is a preliminary model of a product built to test a specific aspect of the design without building the full thing. Prototypes exist on a spectrum from paper sketches to high-fidelity interactive mockups to technical proofs of concept. What they share is that they are not the product: they are a faster, cheaper stand-in for the product, used to explore a question before committing to a full build. A UX prototype tests whether users understand a workflow, can find what they need, and experience the intended journey. It is typically built in a design tool like Figma and requires no working code. A technical prototype tests whether an approach is feasible: can we get the response time we need from this API, can we parse this document format, can this model handle our edge cases? It is a focused engineering experiment, not a user-facing product. The defining characteristic of a prototype is that it is expendable. It exists to answer a question, and once the question is answered, the prototype may be discarded.
Defining an MVP
A minimum viable product is a deployable product designed to test market demand with real users in real conditions. Unlike a prototype, an MVP must actually work. Users interact with it as a real product, not as a test or a demo. It must be reliable enough that users can experience the core value it promises, even if most features are absent. The 'minimum' in MVP refers to the scope of features, not the quality of what is built. An MVP with core features that function correctly and reliably is minimum viable. An MVP that crashes, produces wrong outputs, or loses data is not viable regardless of how few features it has. The purpose of an MVP is to test whether real users, facing real decisions, find enough value in the product to activate, engage, and return. This is qualitatively different from what a prototype tests. A prototype tests design or technical feasibility. An MVP tests market demand.
Proof of Concept: A Third Artefact
The proof of concept (PoC) sits between prototype and MVP and is often confused with both. A PoC is a small-scale implementation that demonstrates whether a specific technical approach is feasible before committing to building a full product on it. Unlike a UX prototype, a PoC involves working code and real technical components. Unlike an MVP, a PoC is not user-facing and does not test market demand. It tests whether the technology can do what you need it to do. A PoC for an AI product might demonstrate that a RAG pipeline can answer questions about a specific document corpus with sufficient accuracy, or that a computer vision model can achieve the required detection rate on a representative image set. The PoC answers: 'can we build this?' before the MVP answers: 'will anyone buy this?'. In regulated sectors, PoCs may also be required to demonstrate technical feasibility to regulators or institutional partners before a full MVP build is approved.
When to Build Each Artefact
Choosing the right artefact for your current question is the key decision. Build a UX prototype when you are designing a new user workflow and want to test comprehension, flow, and usability before writing code. This is particularly valuable when the workflow is complex or novel. Build a technical prototype when your AI or engineering approach is uncertain and you need to validate feasibility before committing to it. This is critical for AI products where model performance on your specific task is unknown. Build an MVP when you have sufficient confidence in your UX and your technical approach and want to test whether the market wants what you are building. The MVP generates the validated learning that guides subsequent investment. The sequence is not always linear: some founders go straight to MVP if their confidence in UX and technical approach is high. Others run multiple prototype phases. The rule is to use the cheapest artefact that answers your current most important question.
Common Mistakes in Prototype vs MVP Decisions
The most common mistake is building an MVP when you should have built a prototype, or vice versa. Building an MVP when technical feasibility is unproven risks investing weeks of production-quality engineering in an approach that fails under real conditions. A short technical prototype phase would have revealed the feasibility question more cheaply. Building a prototype when you need validated market demand confuses investment in UX refinement with the product-market fit question. Users saying a prototype feels nice does not tell you they will pay for the product. A second common mistake is building an MVP to full product quality rather than minimum viable quality. Adding features that are not required to test the core value hypothesis extends timelines and delays the learning that could inform which of those features is actually worth building. Scope discipline, defining exactly what must be true for the MVP to answer its question and building only that, is the hardest part of MVP execution.
How SpeedMVPs Navigates This Decision
At SpeedMVPs, the discovery phase includes an explicit discussion of what artefact the client actually needs. Some clients arrive asking for an MVP when what they need is a technical PoC to validate an AI approach before committing to a full build. Others have already run prototype phases and are ready for production-quality MVP delivery. The right scoping determines both what we build and what we do not build. For AI products specifically, we often recommend a short PoC phase for novel AI approaches where performance on the client's specific data is unknown, followed by a full MVP build if the PoC validates feasibility. This sequencing avoids discovering fundamental technical limitations after investing in a full production build. PoC engagements are scoped separately from MVP engagements. All code from both phases is owned by the client. MVP projects from GBP 8,000, 2-3 week delivery.