MVP vs Prototype vs Pretotype: The Real Difference
A pretotype, a prototype, and an MVP answer three different questions in order: should we build this at all, are we building it right, and does the real product deliver value. Confusing them makes founders build too much before they know demand exists.
Quick Answer: A pretotype tests demand before you build (Alberto Savoia's "the right it"). A prototype tests usability and design — a model, not a shippable product (Jake Knapp's Sprint). An MVP is the smallest real, shippable product that delivers value and drives build-measure-learn (Eric Ries's The Lean Startup). Rough order: pretotype, then prototype, then MVP.
MVP vs Prototype vs Pretotype at a Glance
The three artifacts are not stages of the same thing or synonyms for "an early version." Each is a distinct instrument that answers a distinct question, and using the wrong one wastes the most expensive resource a founder has — time spent building. The table below contrasts them on the question each answers, what each actually tests, and when to reach for it.
| Dimension | Pretotype | Prototype | MVP |
|---|---|---|---|
| Question it answers | Should we build this — is there real demand? | Are we building it right — does the design work? | Does the real product deliver value people will use and pay for? |
| What it tests | "The right it" — genuine market interest before any build | Usability, feel, and feasibility of the experience | A working build-measure-learn loop with real customers |
| Is it a real product | No — a fast fake or stand-in | No — a model or simulation, not shippable | Yes — the smallest shippable product that delivers value |
| Origin | Alberto Savoia, The Right It | Design and UX practice; Jake Knapp, Sprint | Eric Ries, The Lean Startup |
| When to use | Before building — to confirm demand | After demand looks real — to shape the experience | After the design holds up — to learn from a live product |
| Typical effort | Hours to days | Days to a couple of weeks | Weeks and up |
Takeaway: The pretotype checks whether the problem is worth solving, the prototype checks whether your solution is designed well, and the MVP checks whether the real thing earns validated learning in the market. They stack roughly in that order because each de-risks the next — there is little point polishing a design or shipping a product for demand you have not confirmed.
What a Pretotype Tests: Demand Before You Build
A pretotype tests whether you are building "the right it" — whether real demand exists — before you invest in building anything. The term comes from Alberto Savoia, a former Google engineering leader, in his book The Right It. His core distinction: most products fail not because they were built badly (the wrong "it" done right) but because nobody wanted them (the right "it" was never there).
Pretotyping is deliberately fake and fast. A pretotype stands in for the product using the least effort possible, so you can observe how people behave when they believe the thing is real. Because you are not building the product, you can run a test in hours or days and get a market signal before committing engineering time.
It measures behavior, not opinions. Savoia stresses collecting "your own data" — evidence that real people take a real action — rather than asking whether someone likes an idea. A stated "I'd totally use that" is cheap; a click, a signup, or a payment attempt is a signal you can weigh. Some fake-door and demand tests overlap with lightweight MVP tactics like the concierge vs Wizard of Oz MVP approaches, but the intent at the pretotype stage is narrower: confirm interest exists at all before you worry about how to deliver it.
The failure it prevents is the expensive one. Building a polished product for a market that does not want it is the costliest mistake a founder can make. A pretotype front-loads that risk into a test that costs almost nothing, which is why it belongs first in the sequence.
What a Prototype Tests: Usability and Feel
A prototype tests whether you are building the product right — how it should work, look, and feel — through a model that is not meant to ship. Prototypes come from design and UX practice, and the fastest modern articulation is Jake Knapp's Sprint, which compresses prototyping into a structured week of designing and testing a realistic facade.
A prototype is a model, not a shippable product. This is the line that separates it from an MVP. A prototype can be a clickable mockup, a paper sketch, or a convincing front end with nothing real behind it. Its job is to make the experience concrete enough that users can react to it — not to deliver working value to a paying customer.
It answers design and usability questions. Once you believe demand is real, the open questions shift: Is the flow intuitive? Do people understand the value? Where do they get stuck? Can this even be built the way we imagine? A prototype surfaces those answers by putting a realistic simulation in front of target users and watching them struggle or succeed.
Sprint-style prototyping keeps the cost of learning low. Knapp's method exists precisely so teams can test a big bet in days rather than committing months of engineering to a design nobody has validated. You learn how the product should behave before you build the real version — cheaply, and while changes are still easy.
What an MVP Tests: A Real Value Loop
An MVP is the smallest real, shippable product that delivers value and maximizes validated learning — it tests whether an actual product earns a working build-measure-learn loop. The concept is Eric Ries's, defined in The Lean Startup as the version of a new product that lets a team collect the maximum validated learning about customers with the least effort.
The defining trait is that it is real. Unlike a pretotype or a prototype, an MVP actually works and actually ships to real customers who use it to get a real outcome. It can be rough, narrow, and unglamorous, but it delivers genuine value — that is what makes the learning trustworthy. If customers are not really using a real thing, you are still pretotyping or prototyping.
It runs the build-measure-learn loop. Ries frames the MVP as the entry point to a cycle: build the smallest real product, measure how customers behave, and learn whether to persevere or pivot. The MVP is not a one-time test but the seed of continuous, evidence-driven iteration on a live product.
It tests product and business questions, not just interest. By the MVP stage, "do people want this?" should already be answered. Now you are learning whether the real product retains users, whether they will pay, and whether the loop can compound. If you are unsure how an MVP differs from a technical feasibility check, our comparison of MVP vs proof of concept draws that line — the MVP is about validated market learning, not about proving a technology works in isolation.
The Right Sequence for Your Riskiest Assumption
Run these artifacts in the order that attacks your riskiest assumption first — usually pretotype for demand, then prototype for design, then MVP for the real product. The sequence is a default, not a law. What actually decides your next move is which assumption, if wrong, kills the idea fastest.
When demand is the biggest risk, pretotype first. For most new ideas, the deadliest unknown is whether anyone wants the thing at all. Savoia's whole argument is that this is where products die, so a fast pretotype earns its place at the front. Confirm the demand before you spend a day on design.
When the experience is the biggest risk, weight the prototype. If you already know the market wants the outcome — say, in a crowded category where demand is obvious — your risk shifts to whether your particular design is usable and differentiated. A Sprint-style prototype attacks that risk before you build.
When you are ready to learn from a live product, ship the MVP. Once demand looks real and the design holds up, the remaining questions can only be answered by a real product in real hands: retention, willingness to pay, and whether the build-measure-learn loop compounds. That is the MVP's job, and shipping it before the earlier questions are settled is how founders build too much too soon.
The sequence is a risk ladder, not a checklist. You do not always need all three, and you can revisit an earlier rung when new evidence contradicts an old assumption. The discipline is to always spend your effort on the riskiest open question — a principle at the heart of the complete guide to startup idea validation. Structuring that ladder deliberately is exactly the kind of decision a tool like Edmired is built to help founders sequence.
Key Takeaways
- The three artifacts answer three different questions: should we build it (pretotype), are we building it right (prototype), and does the real product deliver value (MVP).
- A pretotype tests demand before you build. Alberto Savoia's The Right It frames it as confirming "the right it" with fast, fake tests that measure behavior, not opinions.
- A prototype tests usability and feel. It is a model — clickable, sketched, or simulated — not a shippable product, and Jake Knapp's Sprint is the fastest way to run one.
- An MVP is the smallest real, shippable product. Eric Ries's The Lean Startup defines it as the version that maximizes validated learning through the build-measure-learn loop.
- The rough sequence is pretotype, prototype, MVP — demand, then design, then a live product — because each stage de-risks the next.
- Let your riskiest assumption set the order. The sequence is a default; spend effort where a wrong answer would kill the idea fastest.
- Confusing the three causes overbuilding. Founders who skip demand tests and jump to an MVP build polished products the market never wanted.
Frequently Asked Questions
Is a pretotype the same as a prototype?
No. A pretotype tests whether you should build something at all — whether real demand exists — using a fast fake before any build, a concept from Alberto Savoia's The Right It. A prototype tests whether you are building it right: a model of the experience used to check usability and design. Pretotype validates the market; prototype validates the solution's design.
Which comes first, a prototype or an MVP?
A prototype comes first. A prototype is a non-shippable model used to test how the product should work and feel, so you refine the design cheaply before building anything real. An MVP is the smallest real, shippable product that delivers value to actual customers. You prototype to get the design right, then build an MVP to learn from a live product in the market.
What is a pretotype in simple terms?
A pretotype is a quick, fake stand-in for a product that you put in front of real people to see whether they would actually use or buy it — before you build anything. Coined by Alberto Savoia, it tests "the right it": genuine demand. Because nothing is built, you can confirm or kill an idea in hours or days rather than months.
Do I need all three for every idea?
No. The three are a risk ladder, not a mandatory checklist. Start with whichever attacks your riskiest assumption first — usually a pretotype to confirm demand. If the market clearly wants the outcome, you might move straight to a prototype and then an MVP. Use only the artifacts that answer questions you cannot yet answer with confidence.