Pretotype vs Prototype: What's the Difference?
A pretotype tests whether you should build something — does real demand exist? A prototype tests whether you can build it well — does it work and feel right? Pretotypes validate the idea before you build; prototypes refine the design once you've committed.
Quick Answer: A pretotype and a prototype answer different questions. A pretotype, from Alberto Savoia's The Right It, tests "the right it" — should this exist, do people actually want it — using fast fake tests that generate real demand data before you build anything. A prototype tests "building it right" — can we make it, and how should it work and feel — using a functional model for usability and feasibility. Pretotype first to validate demand, then prototype to design the solution.
The two words sit one letter apart and get swapped constantly, but they belong to different stages of building. Confusing them is expensive: teams pour weeks into a polished prototype of a product nobody wanted, or they run a scrappy demand test and mistake it for proof that the thing will actually work when built.
Alberto Savoia coined "pretotype" — short for pretend-o-type — in The Right It to name a test that comes before the prototype. The distinction he draws is simple and load-bearing: most products fail not because they were built badly, but because they were the wrong thing to build. A prototype can't catch that failure, because a prototype already assumes you're building the right thing. Here is how the two compare, and how to sequence them.
Pretotype vs Prototype: A Side-by-Side Comparison
The cleanest way to tell them apart is by the question each one answers. A pretotype asks "do people want this?" A prototype asks "does this work and feel right?" Everything else — cost, fidelity, timing — follows from that difference.
| Dimension | Pretotype | Prototype |
|---|---|---|
| Question it answers | Should we build this? Is there real demand? ("the right it") | Can we build this, and how should it work? ("building it right") |
| What it tests | Genuine market interest and willingness to act | Usability, feasibility, and the feel of the solution |
| What it actually is | A fast fake — often no working product behind it | A functional or semi-functional model of the real product |
| Data it generates | Real behavioral demand signals from real people | Usability observations and technical feasibility findings |
| Relative cost | Low — hours to days, minimal engineering | Higher — days to weeks, real design and build effort |
| When to use | Before you commit to building, to validate the idea | After demand is validated, to design and de-risk the build |
Takeaway: A pretotype is a demand test dressed up as a product; a prototype is a product test in miniature. Run them in the wrong order and you risk perfecting something the market never asked for. For a deeper definition of the method, see what pretotyping actually means, and for how prototypes vary in polish, prototype fidelity explained.
When to Choose a Pretotype: Validate Demand Before You Build
Reach for a pretotype when the biggest risk is nobody wants this — when you have an idea but no evidence that real people will act on it. This is the earliest, cheapest stage of validation, and it comes before any meaningful building.
A pretotype's job is to manufacture a real decision. Savoia's whole argument in The Right It is that opinions are worthless as evidence — people say they'd use something and then don't. A pretotype forces a costly signal instead: a click on a "Buy now" button, an email address handed over, a pre-order, a show of up-front commitment. That behavior is data; a survey answer is a guess.
Use a pretotype when:
- You have a new idea and zero real-world demand evidence.
- Building even a rough version would cost real time or money.
- Your key unknown is whether people want it, not how to make it.
- You need to decide fast whether to keep going or kill the idea.
Classic pretotype forms include the fake door (a landing page or button for a product that doesn't exist yet, measuring how many people try to buy), the Mechanical Turk (a human quietly delivering what looks automated), and the pinocchio (a non-functional stand-in someone lives with to test genuine use). None of these require building the actual product — that's the point. They generate demand data before the expensive work starts, which is exactly where pretotyping fits in the broader startup idea validation process.
When to Choose a Prototype: Test Whether You Can Build It Well
Reach for a prototype once demand is no longer the open question — once you've decided the idea is worth building and now need to figure out how. A prototype tests execution, not desirability.
A prototype answers "building it right." Once you know people want the thing, new risks appear: Will the workflow make sense? Can we actually build the tricky part? Where do users get stuck? A prototype is a working-enough model that lets you observe real usage and surface these problems before you commit to full production code. This is the mode the design-sprint approach in Sprint leans on — build a realistic facade quickly, put it in front of users, and watch what breaks.
Use a prototype when:
- Demand is already validated and you're committed to building.
- Your key unknowns are usability, workflow, or technical feasibility.
- You need to see how people interact with the actual solution.
- You want to de-risk design and engineering decisions before scaling them.
Prototypes range in fidelity — from paper sketches and clickable mockups to a functional slice of the real system. Higher fidelity tests the feel and usability more faithfully but costs more to produce. The choice depends on which build-risk you're probing. What a prototype does not do is prove that anyone wants the product — it assumes that question is already settled.
Hybrid Cases: Pretotype First, Then Prototype
The two aren't rivals — they're a sequence. In most healthy validation paths, a pretotype comes first to confirm demand, and a prototype follows to design the solution you now know is worth building.
The order matters because the failures compound. If you prototype first and skip the pretotype, you might build something usable and technically sound that still fails — because it was the wrong it all along. A prototype can tell you the product works; only a pretotype can tell you the product should exist. Starting with the prototype quietly bets that demand is a given, which is the exact assumption most failed products got wrong.
A typical flow looks like this:
- Pretotype — run a fast fake test (fake door, pre-order page) to see if real people act on the idea. Collect behavioral demand data.
- Decide — if the demand signal is strong, proceed; if it's weak, iterate the idea or kill it before spending on the build.
- Prototype — now that demand is validated, build a functional model to test usability and feasibility, and refine how the product works and feels.
- Build — move to production once both the what and the how are de-risked.
Some teams blur the line, and that's fine — a high-fidelity prototype can occasionally double as a demand test if you put it in front of paying-intent users. But treat that as a bonus, not a substitute. The safest habit is to keep the questions separate: validate that it's the right it, then work on building it right.
Key Takeaways
- A pretotype tests "the right it" — from Alberto Savoia's The Right It, it asks whether you should build something and whether real demand exists, before you build anything.
- A prototype tests "building it right" — a functional model that asks whether you can build it and how it should work and feel, referenced in the design-sprint method of Sprint.
- Pretotypes generate real demand data cheaply using fast fake tests like fake doors and Mechanical Turks; prototypes generate usability and feasibility findings using a working model.
- Sequence beats choice: pretotype first to validate demand, then prototype to design the solution you've confirmed is worth building.
- The costly mistake is skipping the pretotype — a polished prototype can prove a product works while it's still the wrong thing to build.
- Cost tracks stage: pretotypes are hours-to-days and low-effort; prototypes take more design and engineering investment because they model the real product.
Frequently Asked Questions
Is a pretotype just a low-fidelity prototype?
No — the difference is the question, not the polish. A low-fidelity prototype still tests how the product works; it assumes you're building the right thing. A pretotype tests whether you should build at all, using a fake stand-in to measure real demand. You can have a scrappy prototype and a scrappy pretotype; only the pretotype validates that people actually want it.
Which comes first, a pretotype or a prototype?
The pretotype comes first. Savoia's whole point in The Right It is to validate demand before investing in a build. Run a pretotype to confirm real people will act on the idea, and only then build a prototype to test usability and feasibility. Prototyping first risks perfecting a product the market never wanted — the most common and expensive failure mode.
Can I skip the pretotype and go straight to a prototype?
You can, but you shouldn't skip it lightly. A prototype tests whether you can build the thing well; it can't tell you whether the thing should exist. Skipping the pretotype quietly assumes demand is a given — the exact assumption most failed products got wrong. If nobody has shown real willingness to act on your idea, run a pretotype first.
What is "the right it" versus "building it right"?
"The right it" is Savoia's term for the what — is this the correct product to build, and does genuine demand exist? A pretotype answers it. "Building it right" is the how — can we make it, and how should it work and feel? A prototype answers that. Most products fail on the first question, which is why pretotyping comes before prototyping.