MVP
How to build an MVP: the smallest version that proves something
An MVP is the smallest version of your idea that lets you test one assumption with real customers. Its measure is what you learn, not what it contains. So the first question is never "what do I build" but "what do I need to know, and what is the least that would tell me". In practice four build types cover almost every case: concierge, Wizard of Oz, landing page and single-feature build. Whichever you pick, write down the number that counts as a yes before you start, and the date on which you decide.
The term is misunderstood in one specific way
Eric Ries made the term popular in "The Lean Startup" in 2011. He defined the MVP as the version of a product that collects the most validated learning about customers for the least effort. Read that sentence closely and the yardstick is not the product. It is the learning.
In everyday use the term has quietly turned into "version one, but with less in it". That reading is what makes MVPs expensive. It sends you into a feature list to decide what to drop. The more useful question is which single assumption, if wrong, would sink the whole thing. Answer that one and the build type often follows by itself, and it is frequently not software.
12 weeks, two routes
Full build first
Build it all, then show it
Eleven weeks of work hang on an assumption nobody checked. If it does not hold, the money is gone and the lesson came at full price.
MVP first
Smallest build, then decide
After two weeks you know whether anyone behaves the way you hope. The remaining ten weeks you either build the right thing or nothing at all.
Both routes cost twelve weeks. The difference is not the effort but the point at which the market gets a say, and how much work is still reversible at that moment. The twelve weeks are an illustration, not a benchmark.
What comes before the first build: validating a business idea, the 5-step test →
Four build types, in ascending cost
Read them top to bottom and stop at the first one that can answer your question. Most founders start at the bottom, because that is the one that feels like building something. Each card also states what the build cannot prove, and that line is the more useful half.
1Concierge
DaysWhat it tests
Does the service carry any value at all?
You deliver the service by hand, for a handful of customers, and you say openly that you are doing it by hand. Nothing is automated, nothing is built. You learn the process a later piece of software would have to reproduce, and you quickly notice where the customer actually gets stuck.
Instead of a booking platform you collect eight bikes yourself, repair them and bring them back. After eight jobs you know what the process really costs.
Proves nothing about the economics at scale. The manual work hides exactly the costs that decide it later.
2Wizard of Oz
1 to 2 weeksWhat it tests
Do customers behave as hoped in front of the interface?
The front looks like a finished product, the back is a person doing the work by hand. The customer notices nothing. That is precisely the difference from the concierge build: here you test behaviour in front of an interface, not the value of the service.
The form promises a time slot in 60 seconds. You assign the slot yourself over the phone; the customer only sees the confirmation.
Does not scale and must not run permanently. Turn it into a business without automating and you grind yourself down.
3Landing page
2 to 5 daysWhat it tests
Is there demand before anything exists?
One page describes the offer including the price and asks for an action that costs something: an email address, a pre-order, a deposit. What you measure is not the visit but the share of people who actually take the action. Allow a payment and you are measuring the hardest commitment available.
A page with a fixed price and time slots, plus 150 dollars of ad budget within a three-mile radius. The question: how many book a slot?
Measures interest in a promise, not satisfaction with a service. A click is not yet a repeat.
4Single-feature build
3 to 6 weeksWhat it tests
Does the one core function actually solve the problem?
You build exactly one function, the right one, and nothing else. No login, no admin area, no second audience. This build belongs at the end of the row, not the start: it is the most expensive one and only pays off once demand and value are already evidenced.
Booking a time slot, and that is all. Payment, reminders and customer accounts wait until enough slots are being booked.
Tempts you to keep building. Without a success criterion fixed in advance, the test quietly turns into a product.
Three examples that were not software
All three are documented publicly, and all three share one trait: what was tested first was demand, not the technology.
Dropbox
Video instead of product
A short screencast showed the synchronisation working before it reliably did. The beta waiting list grew from roughly 5,000 to about 75,000 people.
Zappos
Wizard of Oz
Shoes were photographed in local shops and put online. Each order was bought in the shop and shipped by hand. No warehouse, no stock, a real purchase.
Buffer
Landing page with a price
A page described the tool, a second page showed the plans. Only those who clicked through to the price were asked for an email address.
Careful with the lesson: these are the cases that worked and were written up afterwards. They show that a small build can be enough, not that it is always enough.
In five steps to your first MVP
The first three steps take under two hours together and decide almost everything. Steps 1 and 2 are the ones that get skipped, and skipping them is what turns an MVP into an expensive first draft.
Name the riskiest assumption
45 minutesWrite down every assumption your idea rests on. Then sort them by two questions: how bad would it be if the assumption were wrong? And how certain are you today that it holds? The top of the list is the assumption that costs a lot and is evidenced by little. That one, and no other, is what your first MVP tests.
Result: one sentence starting with "We assume that …" that you could test tomorrow.
Fix the success criterion up front
20 minutesWrite down the number you need to see for the assumption to count as confirmed, and the number at which you drop it. Beforehand, in writing, with a date. Skip this and every result gets read as a success in hindsight, because there is always an explanation for why it went well after all.
Result: a number and a deadline, for example "at least 12 slots booked within 14 days".
Pick the smallest build that produces that number
30 minutesGo through the four build types from top to bottom and take the first one that can measure your criterion. Not the one you would enjoy most, and not the one that looks most finished. The question is not "what can I build" but "what is the least that produces this number".
Result: a chosen build type with a one-sentence reason.
Build it, with a time cap
1 to 4 weeks, set in advanceSet the deadline before you start and treat it as fixed. Anything that does not fit inside the cap gets dropped rather than moving the date. The cap protects not the schedule but the meaning of the result: an MVP that keeps growing ends up testing nothing, because everything around it has changed in the meantime.
Result: something usable in the hands of real customers, not in a demo.
Decide: persevere, pivot or stop
1 hour, on the date you setTake out the criterion you wrote down and compare. Three outcomes are allowed: carry on as planned, change course and test the same question differently, or stop. The third is the most valuable and the rarest. An MVP with no option to stop is not a test, it is phase one of construction under a better name.
Result: a written decision with the number it rests on next to it.
Who is going to use the finished MVP: getting your first 10 customers, one at a time →
MVP, prototype, proof of concept, pilot
The four get used interchangeably and answer four different questions. Picking the wrong one is not a vocabulary problem: it produces an answer to a question you were not asking.
| Term | Question it answers | Who sees it | What comes out |
|---|---|---|---|
| Proof of concept | Is this technically possible at all? | Your own team only | A yes or no on the technology. It says nothing about demand. |
| Prototype | Is the thing understandable to use? | Test participants in a moderated session | Observations about usability. Nobody pays, nobody uses it in daily life. |
| MVP | Do real customers behave as assumed? | Real customers, unmoderated, in daily life | A number measured against a criterion fixed in advance. |
| Pilot | Does the process hold up in operation? | A limited group of real customers over weeks | Operational data: effort, faults, repeat use, cost. |
As soon as money changes hands
The word "beta" is a description, not a legal status. Take a payment, a pre-order or a deposit from a consumer and you are a seller with a seller's obligations. Those include statutory warranty rights that cannot simply be signed away against consumers, information duties before the purchase, and in the EU and the UK a cooling-off period for distance sales. Digital content that starts immediately follows its own rules.
Two practical consequences for the build types above. A landing page that only collects email addresses stays uncritical. A landing page that takes a deposit needs the same information, terms and imprint as a real shop, plus a plan for refunding people if you stop.
General orientation, not legal advice. Thresholds and periods differ by country and change; check the rules that apply where you sell.
Five mistakes that make an MVP worthless
None of them stops you from shipping. All of them stop you from learning anything, which is the only reason the exercise exists.
Treating the MVP as a small product instead of a test. Ask "what do I leave out" and you build a stripped-down product. The right question is "what do I want to know", and the answer to that is often a landing page rather than software.
Starting without a criterion fixed in advance. After the fact, any result can be read as a success. Two sign-ups are evidence of demand or evidence of its absence, depending on what you wrote down beforehand, and only the beforehand version counts.
Counting friends and acquaintances as customers. They say yes because they like you, not because they have the problem. Their commitments are the most expensive kind of feedback, because they feel like proof and are not.
Not deciding once it is built. The MVP is running, the numbers are in, and instead of a decision the next feature follows. That turns the test into a construction phase and leaves the question of whether anyone wants the whole thing unanswered.
Testing everything at once. An MVP meant to settle demand, price, technology and process in one go settles none of them. When the result is poor, there is no way of telling which of the four assumptions gave way.
Frequently asked questions
What is an MVP, in plain terms?
An MVP (minimum viable product) is the smallest version of your idea that lets you test one specific assumption with real customers. The yardstick is learning, not feature count: it is worth as much as it tells you about how your customers behave, not how finished it looks. Very often the smallest version is not software at all, but a page with a price on it or a service delivered by hand.
What does an MVP cost and how long does it take?
That depends entirely on the build type. A landing page plus a small ad budget runs to a few hundred dollars and takes two to five days. A concierge build mostly costs your own time. A built single-feature version takes weeks and reaches four figures as soon as somebody else writes the code. More useful than a price range is a time cap. Decide in advance how many weeks and how much money the answer is worth to you, then pick the build type to match.
How many users do I need for the result to mean anything?
Behaviour that happens rarely needs more observations than behaviour that happens often. In practice, with a clear criterion, 30 to 100 people who actually saw the page and a double-digit number of actions is often enough. What matters more than the count is where they came from: 40 strangers who arrived through an ad tell you more than 200 people from your own network.
Does an MVP have to charge money?
Not necessarily, but a price changes the result substantially. A free sign-up measures curiosity; a pre-order or a deposit measures willingness to pay, and that is the question most ideas fail on. If you do take money, the same obligations apply as to any other sale, even with "beta" written on top.
When is an MVP the wrong approach?
When an unfinished result can cause real harm. That covers medicine, safety, finance and anywhere approval is required. There the smallest testable version is rarely the product itself but a test beside it: a simulation, a preliminary study, a review with domain experts. The thinking stays the same, the build type changes.
Read next
Which assumption should you test first?
The PESSIMIST names the kill criteria of your idea and the TECH ASSESSOR the smallest feasible build. 4 to 12 AI experts, in minutes, from € 5.99.
Assess my idea →