A prototype tests whether an idea is buildable, an MVP tests whether it's wanted, and a V1 is the first version you're prepared to stand behind as a real product. These are three distinct stages with different goals, different audiences and different definitions of done, and conflating them is one of the most reliable ways to waste time early in a product's life.
Why the confusion is so costly
The terms get muddled because people use them loosely in pitch decks, team meetings and blog posts, and nobody stops to pin down what they actually mean. The practical cost is real. I've seen founders build a full-featured V1 when they needed a prototype, burning months on something that only existed to answer a single question. I've seen the opposite too: teams that shipped a scrappy prototype to paying customers and then wondered why churn was brutal. Getting clear on which stage you're actually in changes what you build, how you build it and what counts as success.
What a prototype actually is
A prototype is an artefact built to answer a specific technical or design question, not to serve users. It might be a Figma mockup you click through in a user interview, a rough script that calls an API to prove a data pipeline works, or a single hard-coded screen that exists purely to show a stakeholder what the interface could feel like. The point is not to be used; the point is to reduce uncertainty.
Prototypes are disposable by design. The code quality is irrelevant because the code is not the output; the answer is the output. If you're carrying a prototype forward into your codebase and building on top of it, you've already made a subtle but consequential mistake, because you're now constrained by decisions that were never meant to survive contact with real users.
The right question for any prototype is: what assumption am I trying to kill? If you can't name the assumption, you're probably building something else.
What an MVP actually is
An MVP is the smallest thing you can put in front of real users that tests whether your core value proposition holds. The emphasis is on real users and core value proposition. An MVP is not a prototype, because it has to actually work for someone, and it is not a V1, because it deliberately leaves out everything that isn't essential to the central test. It lives in the world. People use it. Something real is at stake.
The failure mode I see most often is founders treating MVP as a synonym for "a cheap version of the full product". That framing leads to something that has the shape of the product but lacks the spine of it. The question an MVP is answering is: does this problem-solution fit actually exist? Not "can we build this?", not "do people like the design?", but "will someone change their behaviour because of this thing?" That's the bar.
MVPs can and should be rough. They often include manual processes behind the scenes that you'll automate later. The interface might be a form and a spreadsheet. The "product" might be mostly a person doing the work. What matters is that the value delivery is real, even if the mechanism behind it is not yet scalable.
What a V1 actually is
A V1 is the first version of a product you're prepared to own. It has a defined scope, considered architecture, and enough reliability that you can put your name on it without cringing. It's what you build after the MVP has confirmed that the core value proposition is real and you understand well enough who you're building for and what the product needs to do.
V1 is not the finished product. It's not supposed to be. But it is the first version where quality is a genuine commitment rather than a deferred intention. The codebase can be extended. The onboarding works without you holding someone's hand. Errors are handled gracefully. This is the version you launch publicly, write about, and start building a customer base on.
A useful test: if you'd be uncomfortable sending a V1 to a stranger without explaining yourself, it's not actually a V1. It might still be an MVP, or it might be a prototype with delusions of grandeur.
The three stages side by side
| Prototype | MVP | V1 | |
|---|---|---|---|
| Primary question | Is this buildable / does this concept make sense? | Does this solve a real problem people will act on? | Can this scale as a real product? |
| Audience | You, your team, maybe a stakeholder | A small set of real users | The public, or a defined early market |
| Code quality | Irrelevant | Functional, not necessarily clean | Intentional and maintainable |
| Definition of done | The question is answered | The hypothesis is confirmed or rejected | The product is shippable and supportable |
| Typical lifespan | Disposable | Short to medium | Extended, with iteration |
The sequencing mistake most builders make
The most common mistake is not building in the wrong order; it's skipping a stage entirely. Founders who are technically confident often skip prototyping because they'd rather build the real thing. That's understandable, but it means they're burning actual development time to answer questions that a two-hour Figma session could have resolved. Founders who are non-technical often skip the MVP and go straight to commissioning a V1 from an agency, before they've confirmed that anyone wants the thing. Both paths are expensive.
The other sequencing error is staying in MVP mode too long. Once you've validated the core hypothesis, continuing to operate a fragile, underdeveloped product is a different kind of risk: you're eroding trust with early users who have given you the benefit of the doubt. The transition from MVP to V1 is not a celebration; it's a commitment. It means you've learned enough to build the right thing properly.
A real pattern: how I've seen this play out across products
Across the products I've shipped, including Scarab HQ, Legworker and IntentLift, the pattern that works is roughly this: prototype to resolve the one or two questions that genuinely block you from building, then ship an MVP to real users as quickly as the value delivery can be made honest, then treat V1 as the point where you've earned the right to grow. The products that struggled were the ones where those lines blurred, usually because of external pressure to look further along than we actually were.
One thing worth naming: the lines between these stages are not always clean in practice. A product can cycle back through prototype thinking mid-flight when a new capability is being considered. What matters is that you're deliberate about which mode you're in at any given moment, because the mode determines what counts as progress.
What this means when you're deciding what to build next
If you're sitting in front of a new idea right now, the most useful question is not "should I build an MVP?" It's "what do I not know yet, and what's the cheapest way to find out?" Sometimes that's a prototype. Sometimes you already have enough conviction that you can move straight to MVP. Occasionally, if you've done the work before, you already know the problem space well enough to go to V1 with confidence. The stage isn't the goal; reducing uncertainty efficiently is.
Watch out for the language people use to avoid committing. "It's just a prototype" is sometimes honest. Sometimes it's a way of building a V1 while disclaiming responsibility for its quality. Be honest with yourself about which one you're doing.
Can a prototype become an MVP?
Rarely in the same codebase, and usually not cleanly. A prototype is built to answer a question, not to serve users, so its architecture and assumptions tend to be wrong for production use. The better move is to treat the prototype as research, then build the MVP as a deliberate new artefact informed by what the prototype revealed.
When should I start charging for my product?
As early as the MVP stage, if the value delivery is real. Charging early is one of the best signals you can get that the value proposition is genuine. Free users will use almost anything; paying users tell you whether you've actually solved something. Even a nominal amount changes the signal quality dramatically.
What's the difference between an MVP and a beta?
An MVP is defined by its purpose: testing a core hypothesis with real users. A beta is defined by its stage in a release cycle: a product that is feature-complete but not yet publicly launched, typically given to a defined group for testing and feedback before a wider release. You can run a beta at V1 stage. The two concepts are not the same, and they're not interchangeable.
How do I know when I've outgrown the MVP stage?
When the central hypothesis has been confirmed, you understand your users well enough to make deliberate product decisions, and continuing to operate in MVP mode is actively hurting the experience for people who depend on the product. If you're apologising for the product more than you're improving it, that's a sign the MVP has done its job and V1 is overdue.
Do these stages apply to internal tools and not just external products?
Yes, and the logic is identical. Internal tools fail for the same reasons external products do: built before the real problem is understood, over-engineered before the core use case is validated. A prototype to check technical feasibility, an MVP to test adoption within a team, and a V1 when the tool is being relied upon daily. The audience is different; the discipline is the same.