Prototype vs MVP vs v1: What to Build First

Prototype, MVP and v1 get used as if they meant the same thing, and that is one way teams end up spending v1 money to answer a prototype question. Each stage exists to answer a different question, and each is held to a different quality bar. Decide which question you need answered next, and the right thing to build usually follows.

Three stages, three questions

The table matters most in its last column. A prototype is disposable by design. An MVP is real where users touch it and can be held together by hand behind the scenes. A v1 is built to be run, supported and changed for years.

The prototype: learn cheaply, then throw it away

Prototypes come in two kinds, and it helps to say which one you are building.

• A design prototype (clickable screens, even paper sketches) answers "do people understand this and can they finish the task?"
• A technical spike answers "can this be built?" Can the third-party API do what we need, is the matching logic fast enough, will the data import work at all?

What a prototype proves: that the idea can be understood and that the hardest technical piece is possible. What it does not prove: demand. People are polite in test sessions. A tester saying "I would use this" is not the same as a customer coming back next week.

Testing a design prototype does not need a big study. In a Nielsen Norman Group article from March 2000, Jakob Nielsen argued for small rounds of about five users, with a redesign between rounds, and suggested that three studies with five users each beat one study with fifteen. The point for a builder is the loop: test, fix, test again.

Exit criteria for a prototype:

• Test users complete the core task without help, and you have written down what "core task" means.
• The riskiest technical question has a yes or no answer backed by evidence, such as a spike that ran against the real API with measured timings.
• You can list what you would change before building for real.

Set the time box before you start, keep real customer data out of it, and decide in advance that the code gets deleted.

The MVP: find out whether anyone wants it

Eric Ries, who popularized the term, defines the minimum viable product as "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." The same article stresses that an MVP, despite the name, "is not about creating minimal products." "Minimum" describes the effort needed to learn, not the quality of what the user sees.

In practice, that means the parts a user touches must work properly, while the back office can be manual. Imagine a shift-swap tool for restaurant staff. The MVP might let workers post and claim shifts in a clean mobile screen, while a person on your team confirms each swap with the manager by text. The worker gets a real experience. You get real behavior data without building manager approvals, payroll rules or an admin console.

Before you build, write the hypothesis and the number that would count as a pass or a fail. For the shift-swap example, it might be: "At least a third of staff at our three pilot restaurants will post or claim a shift in their first two weeks." That threshold is invented for illustration. Yours should come from what would make the business worth pursuing.

Exit criteria for an MVP:

• The success metric was clearly hit, or clearly missed, so you know whether to continue, change direction or stop.
• Users return without being prompted by you.
• Someone has paid, prepaid or committed in writing, if the business depends on payment.
• You know which manual steps happen most often. Those become the first things v1 automates.

An MVP handles real people's data, so basic obligations start here, not at v1: secure logins, backups, a privacy policy that matches what you actually collect, and a way for users to reach you.

The v1: build it to be run

A v1 answers a different question: can you deliver this to everyone you sell to, without the founder in the loop? The features may not look very different from the MVP. What changes is everything around them.

Exit criteria for a v1:

• Core flows have automated tests, and production has monitoring that alerts a person when something breaks.
• A new customer can sign up and succeed without talking to you.
• You have restored from a backup at least once and know it works.
• Known limits are written down: largest account size you have tested, supported browsers and devices, what happens at those limits.
• Support has an owner and a response target.
• The manual steps from the MVP are either automated or deliberately staffed.

v1 is defined by who you are willing to accept as a customer, not by a feature count. If you can only onboard customers you have met personally, you are still running an MVP, whatever the version number says.

The trap: the prototype that becomes production

A common path looks like this. The prototype demo lands well. Someone asks, "Can we just put this live for a few customers?" The throwaway picks up real users, and with them come its hardcoded settings, missing tests and skipped error handling.

This is an old problem. In The Mythical Man-Month (1975), Fred Brooks wrote in the chapter "Plan to Throw One Away" that the real management question is not whether to build a pilot system and throw it away, because you will, but whether to plan for that or to promise the throwaway to customers. Delivering it, he wrote, buys time "only at the cost of agony for the user, distraction for the builders while they do the redesign, and a bad reputation for the product that the best redesign will find hard to live down."

Ward Cunningham's debt metaphor, from his 1992 OOPSLA experience report, frames the same tradeoff: "Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite." A prototype in production is debt nobody agreed to take on, with no plan to repay it.

Ways to stop it from happening:

1. Label throwaway code at birth. Give it its own repository with "prototype" in the name and a deletion date in the README.
2. Decide before the demo what happens after. Write down, in advance, "if this works, we rebuild the data layer, login and billing properly."
3. Keep a shortcut log. Every time you skip something (validation, tests, error states), add a line. That log becomes the v1 backlog.
4. Promote deliberately. If a piece of prototype code is worth keeping, move it one module at a time, with tests and a review, not by renaming the repository.
5. Never connect a prototype to real customer data. Without real data, a prototype cannot quietly turn into a live product.

Reusing prototype work is fine when it was built on the production stack with tests from the start. Treat that as an exception you have to justify, not the default.

Choosing what to build first

List your biggest unknowns and match them to a stage:

• If the open question is "can it be built?" or "will people understand it?", build a prototype.
• If the open question is "will anyone use it or pay for it?", build an MVP.
• If both are answered and the problem is delivering to paying customers at scale, build a v1.

Skipping a stage is reasonable when its question is already answered. Rebuilding an internal tool that people already use every day, for example, may go straight to v1, because demand is not in doubt.

Whatever you pick, write the question at the top of the plan along with the evidence that would answer it. When you have that evidence, stop building that stage, even if there are features left on the list.