On this page
Real users, one task, as soon as possible
With an MVP, a minimum viable product, you learn whether your idea works before you build the whole thing. Not a clickable mock-up, not a slide deck: software with a login, real data and the one task that matters. Everything that task does not need, waits.
The word people forget is viable. An MVP is small, but not half-built. The features in it work well enough for someone to use them every day. Only then do you see real behaviour instead of polite opinions in a meeting.
Frank Robinson in 2001, Eric Ries in 2011
The term comes from Frank Robinson and his consultancy SyncDev, which first used it in 2001. Robinson was after the product with the highest return on risk, for vendor and customer alike: too small and nobody buys, too big and you spend months on what nobody asked for. Steve Blank, who wrote the books on customer development, later credited him plainly: Frank coined the term.
Eric Ries made it famous. On 3 August 2009 he wrote on his blog that an MVP is the version of a new product that lets a team collect the most validated learning about customers with the least effort. In The Lean Startup, out on 13 September 2011, the MVP became the first step of a loop: build, measure, learn. You build the smallest thing that can prove something, measure what users do, then decide to persevere, pivot or stop.
Ten wishes, three features
A cleaning company with 25 staff (example)
Later, once the first version works
- Client portal
- E-invoices over Peppol
- Routes on a map
- Chat with the office
- Monthly reports
- Client ratings
- Link to the accounting package
Then the loop runs
- Build6 weeksOnly the three functions, but real: login, own data, an admin side.
- Measure4 weeks with 5 cleanersHow many calls still reach the office? How many schedules are wrong?
An MVP is not the cheapest version of the whole plan. It is the smallest version that answers a real question: does this work for our people?
Ten wishes, three features: a cleaning company
Take a cleaning company with 25 staff that plans everything in a spreadsheet and a group chat. The owner writes a software requirements specification with ten wishes, from a weekly schedule to client ratings. Build everything at once and you wait months for something that may not take with the people who must use it.
The question that settles scope: which problem costs the most today? Here it is scheduling. Every morning staff call the office to ask where to go, and one sick call wrecks half a day. So the MVP gets three functions: a weekly schedule per client and per cleaner, the day plan on each cleaner's phone, and a button to report an absence. Invoices, routes, a client portal and reports wait.
What it costs and returns, in time and money. Say the quote for all ten functions comes to 60,000 euro; that is a worked example, not our price. The three functions of the MVP, with login and an admin side, are then roughly a third of the work. They reach the first users in six weeks instead of six months. If the planner then spends six hours a week less on the phone, you know within a month whether the rest of the list is worth the money. For what hours cost across Europe, see web developer hourly rates; for whether to build at all, build vs buy software.
| Form | Prototype | Proof of concept | MVP | Full version |
|---|---|---|---|---|
| Goal | Show what it looks like | Prove it is technically possible | Learn whether people use it | Carry the whole job |
| Who uses it | You and a few testers | The build team | Real users, a small group | Everyone |
| Real data | No | Sometimes | Yes | Yes |
| Typical length | Days | One to three weeks | Six to twelve weeks | Months, in phases |
| What you know after | Whether the idea is clear | Whether the integration or technique works | Whether the idea has value | What the next phase should be |
Five decisions for the first version
- Write the problem in one sentenceNot the solution, the problem: "staff do not know in the morning where to go". Every feature must make that problem smaller.
- Pick the smallest group of usersFive people, one team, one site. A small group that uses it daily teaches you more than a hundred people who open it once.
- Cut until it hurtsFor every wish ask: does the MVP work without it? Then it goes on the later list. An export to a spreadsheet often replaces reports.
- Agree what you measureOne or two numbers fixed before the build: calls to the office, scheduling errors, hours of the planner. Without a measure, every MVP turns into an opinion.
- Plan the decisionA date, four weeks after launch, on which you decide: persevere, pivot or stop. Only then does the next feature join the list.
Small is not the same as sloppy
Small is fine, broken is not. An MVP with scheduling errors does not measure whether the idea works, only whether people tolerate errors. Login, security and backups belong in it from day one, even in the smallest version.
Where it goes wrong
The MVP becomes a pilot that never ends. Without an agreed measure and a decision date, the first version lingers. Set what good enough means up front, as you would with an OKR, and check the ROI with real hours.
The MVP gets thrown away. Build the first version in a toy tool and you start again after it succeeds. Build it on the same foundation as the product that follows, so you extend instead of restart. Work in short rounds, as Scrum does, and keep it simple to use: good UX decides whether your MVP gets used at all.
The MVP is too big. The most common mistake. If you doubt whether a feature belongs in it, it does not.
An MVP is also the natural start for anyone who wants to sell a product to others, a SaaS. If the first version must run on your staff's phones, a PWA is often faster and cheaper than two store apps.
Before you have the first version built
How long does it take to build an MVP?
For an internal tool or a simple app, usually six to twelve weeks if the scope stays small. If it runs past three months, it is no longer an MVP but the first version of the whole plan.
What is the difference between an MVP and a prototype?
A prototype shows what something will look like, often as a clickable mock-up without real data. An MVP actually works: people log in, enter data and do their job with it. So an MVP measures behaviour, a prototype only a first impression.
What does MVP mean in business?
The same as in software: the smallest offer you can put in front of real customers to learn whether they want it. Outside business, in sport, MVP means most valuable player.
Should an MVP be built in-house or outsourced?
Outsource when you lack the people or the time, and keep the product decisions yourself. Ask for a fixed price per phase, the code in your own repository, and the same stack for the MVP as for what follows, so a later in-house team can take over.