MVP vs Prototype vs Proof of Concept (2026)
TL;DR: MVP vs prototype vs proof of concept comes down to one question each. A proof of concept (PoC) asks "can this be built?", a prototype asks "can people understand and use it?", and an MVP (minimum viable product) asks "will people use, keep and pay for the smallest real version?". What none of the three asks is the question most failed startups got wrong: do enough people want this to act on it? That is a fourth step, a demand test (a landing page with a signup or pre-order, an explainer video, or a service you run by hand), and it can come before or between the other three. Build whichever answers your biggest risk. Below: definitions, a comparison table, published time and cost ranges, where "MVP" came from, seven classic examples and a decision tree.
MVP vs prototype vs proof of concept at a glance
Most guides to MVP vs prototype vs proof of concept are written by agencies that sell the building, so they present the three as a staircase you climb in order, with an invoice at each step. It is more useful to treat each as a tool that answers one question, and to build only the ones whose question you cannot already answer. Here is the short version, with the fourth step added.
| Proof of concept | Prototype | Demand test | MVP | |
|---|---|---|---|---|
| Question it answers | Can it be built? | Can people use it as designed? | Do enough people want it to act? | Will people use, keep and pay for it? |
| Who sees it | Your team, an investor, a technical buyer | 5 to 10 target users, your team | Strangers in your target market | Real early customers |
| Fidelity | Rough, works in one narrow case | Looks real, usually does not work | A page, a video or a manual service | Real, small, may be partly manual |
| Typical time | Days to 6 weeks | 1 to 4 weeks | A few days to 2 weeks | Weeks to 6 months |
| Typical output | A working spike and a yes or no | Usability findings and a revised design | Signups, answers, clicks, replies, deposits | Usage, retention and revenue data |
| What it proves | Feasibility | Usability and comprehension | Demand | Value and retention |
| What it cannot prove | That anyone wants it | That anyone wants it or will keep using it | That they will keep using it | Much, if nobody came to try it |
Time ranges are published ranges from the sources in the time and cost section below; the demand test range is our estimate.
The table hides one important asymmetry. A failed proof of concept or a confusing prototype is cheap news: you learn it in weeks and change course. A failed MVP that nobody wanted is expensive news, because you learn it after months of building. In CB Insights' March 2026 analysis of 431 venture-backed startups that shut down since 2023, poor product-market fit was a cause in 43% of the 385 where a reason could be identified. Feasibility and usability rarely kill startups on their own. Building something too few people want does.
What is a proof of concept?
A proof of concept is the smallest piece of work that shows whether the core technical idea works at all. It answers an engineering question: can we get this model to run under 200 milliseconds, can we read data from this bank's API, does this sensor survive a washing machine?
Who it is for: your team, and sometimes an investor or an enterprise buyer who will not sign until they see the hard part working. It is rarely shown to end users.
What it looks like: a script, a notebook, a breadboard. It works in one narrow case with hand-fed data, and its code is usually thrown away.
How long it takes: UXPin, a design tool company, puts a PoC at days to a few weeks; Cleveroad, a development agency, quotes 3 to 6 weeks and $15,000 to $30,000 when an outside team builds it. A solo founder testing one risky integration may need only a few evenings.
What it does not tell you: whether anyone wants it, can use it or will pay. A working PoC proves the door can be built, not that anyone will walk through it.
A real example: Gmail's content-targeted ads began as a few hours of hacking. Paul Buchheit wrote that most people at Google believed targeting ads to arbitrary content would need "some kind of fancy artificial intelligence", so he rewired a safe-search classifier to pick the most relevant ad for each email and showed it on the internal Gmail prototype, used by about 100 Googlers. The ads turned out to be surprisingly relevant, which settled the feasibility question, and the idea became what is now known as AdSense.
Pros: cheap and fast; settles a technical question before money goes into design; convinces technical buyers. Cons: says nothing about demand or usability; easy to keep polishing; the code is usually thrown away.
When you can skip it: most of the time, for ordinary software built on standard parts. If your honest answer to "could this be built?" is "obviously yes", a PoC is procrastination with a technical label.
What is a prototype?
A prototype is a model of the product that people can look at or click through, built to learn whether they understand it and can use it as designed. It answers a design question: do people know what this screen is for, can they complete the main task without help, what do they expect to happen next? In the usual PoC vs prototype vs MVP sequence, it is the middle step.
Who it is for: a handful of people from your target market, plus your team.
Fidelity comes in three rough levels:
- Low fidelity: paper sketches. Minutes to make, good for testing the order of steps.
- Medium fidelity: grey wireframes linked in a design tool, for navigation and labels.
- High fidelity: clickable screens that look finished, with fake data, for comprehension and first impressions.
How long it takes: UXPin says one to four weeks depending on fidelity; Cleveroad quotes three to four weeks and $5,000 to $15,000 for an agency-built one.
How to test one: Nielsen Norman Group's rule of thumb is that five users find about 85% of the usability problems, so give five people a task, stay quiet and note every hesitation.
A real example: before the PalmPilot existed, Jeff Hawkins tested its design with a wooden model. The Computer History Museum, which holds it, says he used a chopstick for a stylus, "took pretend notes in meetings, and counted the steps it took to perform common tasks." No electronics, just the size and the steps.
Pros: cheap to change; finds most usability problems with a handful of people; needs no engineering. Cons: praise is not commitment; fake data hides real-world problems; a polished one is easy to mistake for validation.
What it does not tell you: whether people want the product, and whether they will keep using it. This is the mix-up that costs founders the most: "I would definitely use this" from someone clicking through your screens is a compliment, not a commitment.
Proof of concept vs prototype
The PoC vs prototype question is easy once you name the risk each one retires. A proof of concept retires technical risk and is built for engineers. A prototype retires usability risk and is built for users. A PoC usually works but looks terrible; a prototype looks right but does not work. Something technically new with a familiar interface may need only the PoC; something technically ordinary with a new interaction may need only the prototype.
What is an MVP?
An MVP is the smallest real version of the product that real customers can use, so you can learn from what they actually do rather than what they say. Eric Ries's definition from 2009 is still the best one: the minimum viable product is "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort".
Who it is for: real early customers, usually a small group you can talk to. If you plan to let them in in waves, the mechanics are the same as when you run an early access program.
What it looks like: smaller than you think, and not always software. It does the main job for real, even if a person does part of the work behind the scenes, and skips almost everything else.
What it tells you: whether people come back without being reminded, whether they pay, and which part they actually value.
What it does not tell you: much of anything, if nobody came to try it. An MVP launched to no audience produces silence, and silence is ambiguous: it could mean nobody wants the product, or that nobody heard about it.
Pros: the only step that shows real retention and payment; gives you real users and sometimes first revenue. Cons: the slowest and most expensive of the four; scope creeps easily; tells you little without an audience.
Where the term MVP came from
The phrase is older than the lean startup movement. Frank Robinson, CEO of the product development firm SyncDev, wrote that his firm first used the term in 2001 and defined it by risk: the unique product with the best "return on risk for both the vendor and the customer". Steve Blank, quoted on the same page, credited Robinson with coining the term and said he liked it better than "minimum feature set", which Blank had used in his first book.
Eric Ries made the term famous, on his blog from 2009 and in his 2011 book The Lean Startup, and shifted the emphasis from risk to learning.
How the meaning drifted
Over fifteen years, "MVP" drifted in two opposite directions.
It got bigger. In agency proposals and job posts, "MVP" often means "version 1": a full product with fewer features, months of work and a budget in the tens of thousands. Ries warned against this in the same 2009 post: "MVP, despite the name, is not about creating minimal products." He described spending two weeks building a feature at IMVU that nobody wanted.
It got worse. The other drift treats "MVP" as permission to ship something broken. Henrik Kniberg's often-shared drawing answers it: don't deliver a wheel, then a chassis, then a car; deliver a skateboard, then a bike, then a car, because the skateboard is "actually a usable product". Minimal, yes. Unusable, no.
MVP vs prototype: key differences
The cleanest test for prototype vs MVP: does it do the job for real? A prototype looks like the product so people can react to the design. An MVP does the job, for a real person with a real problem, even if it is small, ugly or run partly by hand. You can learn from a prototype in an afternoon whether people understand it. You need weeks of an MVP to learn whether they keep using it.
| Prototype | MVP | |
|---|---|---|
| Purpose | Test whether people understand and can use the design | Test whether people use, keep and pay for it |
| Audience | 5 to 10 target users and your team | Real early customers |
| Functionality | Looks real; little or nothing works | Does the main job for real, maybe partly by hand |
| Cost (agency estimate) | $5,000 to $15,000 | $50,000 to $150,000 or more |
| Time | 1 to 4 weeks | A few weeks to 6 months |
| Feedback | What people say and where they hesitate | What people do: return visits, usage, payment |
One related term: a pilot is a limited real deployment, usually with one business customer, which is closer to an MVP than a prototype. And a beta launch describes how finished the product is when you open it to people, not which of these questions it answers.
The missing step: a demand test
A PoC proves you can build it, a prototype that people can use it, and an MVP that they keep using it, but only after you have built it. None answers the question in between: do enough of the right people want this to take a real action before it exists?
That is what a demand test does. It also goes by smoke test, and one variant (a button for a feature you have not built that records who clicks) is often called a fake door test. Ries named the ad version in his MVP post: "a simple AdWords smoke test". Michael Seibel of Y Combinator said in a 2019 talk that founders should build a lean MVP in "weeks, not months", and that some startups "just start with a landing page, and a spreadsheet".
A demand test is not a survey; "would you use this?" measures politeness. It asks people to do something that costs them a little: give an email address, answer a qualifying question, choose a price, reply to a personal message, book a call or put down a deposit. The more it costs, the stronger the signal.
Four ways to run one
A landing page with a signup. One page that says who it is for and what problem it solves, with a form to join a list and one qualifying question ("How soon do you need this?") that separates the curious from people with the problem. It is the cheapest format; an idea validation landing page is exactly this, and these waitlist landing page examples show how others wrote theirs.
A pricing step or pre-order. Put a "see plans" button between the pitch and the signup, and record which plan people click. That tells you who would consider paying, not just who is curious. A real pre-order or deposit is the strongest version, but it needs a way to take money and a promise you can keep.
An explainer video. A short screen recording or demo of the product as it will work, with a signup link. It suits products that are hard to describe in a sentence and easy to understand when you see them.
A manual service. Do the job by hand for a few customers and see whether they come back and pay. This is both a demand test and a type of MVP (more on that below), and it answers value questions a page cannot.
Three classic examples, verified
Dropbox's demo video (2008). In March 2008, Dropbox posted a three-minute demo of the product as it was meant to work, and its beta waiting list went from about 5,000 to about 75,000 signups overnight. Those new names had seen a video, not used a product; how Dropbox grew with a referral program is the later story.
Buffer's two pages (late 2010). Before building his tweet scheduling tool, Joel Gascoigne tested a two-page site that described the app and asked for an email, then added a pricing page between the two to see which plans people clicked. He described the test in a post published in February 2011, by which time the app was built and had paying customers.
Zappos' photographed shoes (1999). Nick Swinmurn wanted to know whether people would buy shoes online without trying them on. Instead of buying stock, he went to a shoe store and offered a deal, which he later recounted to Fortune: "I'll take some pictures, put your shoes online, and if people buy them, I'll buy them from you at full price." Every order was a real purchase by a real customer, with no inventory risk.
How to read the results
Decide your pass mark before the first visitor arrives, because afterward any number looks encouraging: who you will send (one audience, not friends), how many visitors make a fair read, and what result means "build", "change the pitch" or "stop".
Here is a worked example with illustrative numbers. A founder building scheduling software for physiotherapy clinics sends 600 visitors from two clinic-owner communities and a small ad test to a one-page site. 72 sign up (12%). On the form, 30 of them choose "I would switch this quarter" to the question "How soon would you change your scheduling tool?". The founder emails 20 of those 30 personally, and 8 reply and book a call.
The 30 qualified answers and the 8 calls justify building an MVP, and those 8 people are its first users; the 72 signups alone would not. If the signups come but the qualifying answers do not, the pitch is reaching the wrong people or promising the wrong thing; why a waitlist is not converting walks through the usual causes. If you want a rough revenue picture from numbers like these, the pre-launch MRR calculator turns a list size and an assumed conversion into a range.
Getting the 600 visitors is its own task: how to get your first 100 waitlist signups and how to promote your waitlist cover the channels. For a wider set of methods and the tools behind them, see the guide to idea validation tools.
Minimum viable product examples by type
"MVP" covers several quite different things. These are the common types, each with a real example from a primary or well-documented source.
| MVP type | What you build | Example | What it answered |
|---|---|---|---|
| Concierge | Nothing automated. You deliver the service by hand, and the customer knows a person is doing it | Food on the Table: Manuel Rosso accompanied shoppers and emailed personal meal plans before writing software | Which steps matter and whether people would pay |
| Wizard of Oz | A front end that looks automated, with a person doing the work behind it, and the customer does not know | Zappos: orders on a real-looking store, filled by buying shoes at a local shop | Whether people would buy shoes online at all |
| Single feature | Software that does one job and nothing else | Buffer's first version: queue tweets so you do not schedule each one, built in seven weeks | Whether people use and pay for the core job |
| Piecemeal | Off-the-shelf tools stitched together | Groupon: a WordPress blog with one deal a day, coupon PDFs made in FileMaker and emailed from Apple Mail | Whether daily group deals would sell |
| Landing page or video | A page or demo of the product, with a signup | Dropbox's three-minute demo video | Whether people wanted it before it could scale |
Kromatic's Real Startup Book defines the Wizard of Oz test as an experience "that looks fully built to the user" while an operator produces the response, and files Zappos under it. It lists DoorDash's start as a concierge case: the founders listed local menus on a basic site and delivered the food themselves.
Andrew Mason was blunt about Groupon's first version: customers emailed the size and color of a t-shirt because there was no form for it, and at 500 sushi coupons a day they were still sending 500 PDFs through Apple Mail. It was, in his words, "enough to prove the concept."
Two more early MVPs show the range: in October 2007 Airbnb began as an air mattress in its founders' San Francisco living room, offered to travelers during a design conference, and Product Hunt began as an email list built with the link-sharing tool Linkydink that Ryan Hoover shared with a couple dozen people he knew.
Notice that two of the five types (concierge and Wizard of Oz) involve almost no software. If your product's value is in the outcome, not the interface, a manual MVP often teaches you more in two weeks than a coded one does in three months.
Which to build first: match it to your biggest risk
The textbook answer to MVP vs prototype vs proof of concept is an order: PoC, then prototype, then MVP. It is right for some products and wasteful for most. A better rule: write down the assumption that would kill the business if it were wrong, and build the cheapest thing that tests it.
| If your biggest risk is | Ask yourself | Build first | Example |
|---|---|---|---|
| Technical | Can this even work? | Proof of concept | A new speech model that must run on a phone |
| Usability | Will people understand how to use it? | Prototype | A new way to edit video with text |
| Demand | Does anyone want this enough to act? | Demand test | Scheduling software for a niche you have never sold to |
| Value and retention | Will they keep using it and pay? | MVP (often concierge or single feature) | A habit app where the hard part is week 3, not day 1 |
A few patterns from the table:
- Most software startups should start with the demand test. For an ordinary app, technical risk is low and usability problems are fixable later.
- Deep tech starts with the proof of concept. There is no point testing demand for something you may not be able to build. Seibel's own caveat was that "it is hard to build a rocket in a couple of weeks."
- The demand test can come between steps. After a working PoC, before investing in design; or after a prototype, using its screenshots on the page.
- Many products need only two of the four, often a demand test and a single-feature MVP.
How long does it take to build an MVP (and a prototype or PoC)?
Published ranges vary because the people publishing them build different things for different budgets. Here is who said what.
| Step | Typical time | Agency cost estimate | Sources |
|---|---|---|---|
| Demand test | A few days to 2 weeks | Little or none (tools, optional ad spend) | Our estimate |
| Proof of concept | Days to 6 weeks | $15,000 to $30,000 | UXPin (days to a few weeks), Cleveroad (3 to 6 weeks) |
| Prototype | 1 to 4 weeks | $5,000 to $15,000 | UXPin (1 to 4 weeks), Cleveroad (3 to 4 weeks) |
| MVP | A few weeks to 6 months | $50,000 to $150,000 or more | Y Combinator (weeks, not months), UXPin (1 to 3 months), Cleveroad (2 to 6 months) |
Cost figures are one agency's estimates for outsourced work, not what a founder building alone spends.
The demand test is the cheapest step on the chart and the only one that needs no product. The MVP range is enormous, and where you land in it depends mostly on discipline. Ries wrote that IMVU's first MVP took six months, which was still a big improvement over the five years he had spent on a previous company before launching. A concierge MVP can start next Monday.
If you are quoted six months for an MVP, ask which assumption it tests. If the answer is "all of them", it is a version 1, not an MVP.
How AI app builders changed the math in 2025 and 2026
The biggest change to the MVP vs prototype vs proof of concept question since Ries's book is the cost of building a first version. AI app builders turned "prototype" and "first MVP" from weeks of work into days for many ordinary web apps.
The adoption numbers are large. In July 2025, Lovable said it had passed $100 million in annual recurring revenue eight months after launch and that more than 100,000 new projects were being created on it each day (company figures). In March 2025, Y Combinator managing partner Jared Friedman said that a quarter of its Winter 2025 batch had 95% of their code generated by AI, and added that these were highly technical founders who could have built it by hand.
What got cheaper:
- High-fidelity prototypes. A working one can now come from a few paragraphs of description, which often makes a separate mockup unnecessary.
- Single-feature MVPs for standard software. Sign-in, a database and one core feature are what these tools do best.
What did not get cheaper:
- Demand. Building faster creates no one who wants the product. It makes the demand test more important, because it is now easy to build three products nobody asked for in a month.
- Hard technical problems. The proof of concept for a genuinely new technique still needs real engineering. Speed gains are also not universal: in a 2025 randomized trial, METR found that experienced open-source developers took 19% longer on tasks in their own mature codebases when allowed AI tools, even though they expected to be 24% faster.
- Security. An AI-built app that holds real customer data needs real access checks, however quickly it was made.
There is also a quieter risk: a prototype that looks finished gets treated as validation. A polished AI-built demo that friends praise has answered the usability question at best, not the demand question. If you built with Lovable, Bolt, v0 or Replit, a waitlist for your AI-built app can collect interest while you find out.
Common mistakes
An MVP that is not minimal. The most expensive mistake. Every feature added before launch is an untested guess. If someone could still get the main job done without it, cut it.
A prototype mistaken for validation. Five people saying "I love it" tells you the design is clear, not that they will switch, pay or come back.
Skipping the demand test because building is fast. The weekend build is cheap; the next three months of maintaining and marketing something nobody asked for are not.
Counting signups from friends as demand. Friends want you to succeed, which makes them poor judges of whether strangers will. And 500 emails from a vague page are weaker evidence than 30 strangers who answered a qualifying question the right way.
A proof of concept that never ends. A PoC has one question. Once it is answered, stop and throw the code away.
Launching an MVP to nobody. Build the audience while you build the product; silence after a launch with no audience tells you nothing. The SaaS pre-launch marketing playbook covers how to do both at once.
A simple sequence for a solo founder
For ordinary software built alone, this order fits most cases:
- Write the riskiest assumption down in one sentence.
- Run a demand test for one to two weeks, with one qualifying question and a pass mark set first.
- Email the people who passed and ask how they handle the problem today.
- Build the smallest MVP, concierge or single feature, let those people in first, and check the SaaS launch checklist before opening wider.
Add a prototype only if the interaction is new, and a proof of concept only if the technology is.
Where LaunchList fits
LaunchList is pre-launch waitlist software for founders, and it fits one step in this post: the demand test, and the hand-off from it to your MVP. It does not build prototypes or MVPs, run your interviews or take payments. What it does:
- Start the test today. Write one sentence about what you are building and the AI drafts the page, which you can then reshape in the waitlist page editor and publish on a launchlist.page link. Already have a site? Put the form there instead; what a pre-launch waitlist is explains both routes.
- Ask the question that qualifies. Every plan lets the waitlist form builder add a dropdown, a single or multiple choice, or a long-text answer, which is how you tell "would switch this quarter" apart from "just curious".
- Know which channel worked. On every plan, a hidden field saves the tag from your link (for example
?source=newsletter), so you can see which community or ad sent the qualified people rather than the most people. - Watch for sharing. Each person who joins gets a referral link and sees their place in line, and referral waitlist software shows who brought friends: few people pass on something they do not want.
- Open the doors one person at a time. Once the MVP works, send early access invite codes to one person or up to 1,000 at once. Each gets a personal code and an email that leads to their private status page. Personal invites come with every plan, and the Free plan has a fixed allowance (pricing has the details).
- Announce it. From the Collect plan, you can email your waitlist the day the MVP opens.
Once those first users are in, converting a waitlist into paying customers is the next guide to read.
MVP, prototype and proof of concept FAQ
What is the difference between an MVP, a prototype and a proof of concept?
Each answers a different question. A proof of concept asks whether the core technology can work at all, and it is usually built for your own team. A prototype asks whether people understand and can use the product as designed, and it is usually not real software. An MVP asks whether people will use, keep and pay for the smallest real version. None of the three asks whether enough people want the product to act on it, which is the job of a demand test.
What is an MVP?
An MVP (minimum viable product) is the smallest real version of a product that lets you learn from actual customers. Eric Ries defined it in 2009 as the version of a new product that collects the maximum amount of validated learning about customers with the least effort, and he added that it is not about creating minimal products. It can be software, but it can also be a service you run by hand behind a simple website.
Which comes first: a proof of concept, a prototype or an MVP?
Whichever answers your biggest risk. If you are not sure the technology works, start with a proof of concept. If you are not sure people can use your design, start with a prototype. If you are not sure anyone wants it, run a demand test before either. If people want it and can use it but you do not know whether they will keep using it or pay, build the MVP. Many software products need no proof of concept at all.
Is a prototype the same as an MVP?
No. A prototype looks like the product so people can try the design, but it usually does not do the work: the data is fake and nothing is saved. An MVP does the work for real users, even if it is small or partly done by hand. A prototype can tell you people understand the product. Only an MVP can tell you they keep using it.
What is the difference between a PoC and a prototype?
A proof of concept tests whether something can be built and is usually ugly, internal and thrown away. A prototype tests whether people can use the design and is usually shown to target users. A PoC answers an engineering question; a prototype answers a design question. Neither tells you whether people want the product.
How long does it take to build an MVP?
Published ranges run from a few weeks to about six months. Y Combinator's Michael Seibel says most founders should build a lean MVP in weeks, not months. A design tool vendor puts it at one to three months and one development agency at two to six months. Eric Ries said IMVU's first MVP took six months. Hard technology such as hardware takes longer.
How much does an MVP cost?
It depends on who builds it. One development agency quotes $50,000 to $150,000 or more for an MVP, $15,000 to $30,000 for a proof of concept and $5,000 to $15,000 for a prototype. A founder who builds it alone with an AI app builder may spend a monthly subscription and their own time. A concierge MVP, where you deliver the service by hand, can cost almost nothing but hours.
What is a demand test?
A demand test checks whether enough of the right people want a product to take a real action before you build it: join a list, answer a qualifying question, click a pricing plan, reply to an email or pay a deposit. The usual forms are a landing page with a signup, an explainer video, a small ad test or a manual service. Dropbox, Buffer and Zappos all ran a version of one.
Who coined the term minimum viable product?
Frank Robinson of the product development firm SyncDev, who says he first used the term in 2001 and defined it as the product with the best return on risk for both the vendor and the customer. Steve Blank said he preferred it to his own phrase, minimum feature set. Eric Ries popularized it from 2009 and in his book The Lean Startup.
Do I still need a prototype if I use an AI app builder?
Often you can skip the clickable mockup, because an AI app builder can produce a working first version in days. But what that first version answers does not change: watching five people try it tells you whether they understand it, and only real usage over weeks tells you whether they keep it. A fast build also makes it easier to skip the demand test, which is the step most worth keeping.
