An MVP, or minimum viable product, is the smallest version of a product that lets you test your most important assumption on real users. It isn't a "cheap version of the app" but the shortest route to an answer to one question: does anyone really need this, and will they do what you expect?
If you came here from games or sports: there MVP stands for "most valuable player", the best player on the team. This article is about the product.
Where the term comes from
The term appeared in the early 2000s and was popularised by Steve Blank and Eric Ries. In "The Lean Startup", Ries describes an MVP as the version of a product that lets you collect the maximum amount of validated knowledge about customers with the least effort. Two words matter here: knowledge and effort. An MVP is there to teach you something, not just to exist.
What the three letters mean
- Minimum — only what is needed to test one assumption. Every extra feature lengthens the time to the first answer.
- Viable — the product must really work and deliver value. A crumbling mock-up won't tell you whether people want the solution, only that they don't want something broken.
- Product — something people use or pay for. A "would you buy this?" survey is research, not a product.
The most common mistake is to hold on to the first letter only. "Minimum" without "viable" gives you a product that proves nothing.
Types of MVP
Not every MVP is an app. You start with the cheapest approach that will give a credible answer.
Sign-up page (smoke test). You describe the product as if it already existed and measure how many people leave an email address or click "buy". It tests demand before a single line of product code exists.
Concierge MVP. You deliver the service by hand for the first few customers. You learn right away what they pay for and what matters to them, and only then do you automate.
"Wizard of Oz" MVP. The customer sees a finished product, but behind the scenes a person does part of the work. You test whether people use the solution before you build costly automation.
Single-feature product. A working app that does one thing well: for example, only booking, with no loyalty programme, chat or reports. This is the most common form when the assumption is about whether people will use it regularly.
MVP from ready-made blocks. A form, a spreadsheet, a payment tool and automation instead of a custom system. Quick and cheap, but it has limits once traffic grows.
Well-known examples
- Dropbox, before building the full product, showed a short video of how file syncing would work. The waiting list grew from a few thousand to tens of thousands of people overnight. It was a demand test, not an app.
- Zappos had no warehouse at the start. The founder photographed shoes in local shops, and when an order came in he bought the pair and shipped it. He was testing whether people would buy shoes online.
- Airbnb started by renting out air mattresses in the founders' apartment during a conference in San Francisco, when hotels were full. A simple site, a few guests, real money.
In all three cases the first version tested one assumption that decided the whole idea.
What an MVP is not
It isn't a prototype to show investors. A prototype tests whether the solution can be understood and used. An MVP tests whether people use it or pay for it. Both are useful, but they answer different questions.
It isn't a first version with half the features. If the MVP feature list looks like a one-year plan cut in two, it isn't an MVP. It's a full product that just takes longer to build.
It isn't sloppiness. A narrow scope is no excuse for bugs, slow performance or unsafe handling of data. Few features, but done properly.
It isn't the end of the work. An MVP is the start of a learning cycle. Data, decisions and further versions come after it.
How to choose the scope of an MVP
- Write down your assumptions. Who has the problem, how do they solve it today, what does it cost them, why would they choose you.
- Pick the riskiest ones. The one that, if false, cancels out the rest. It usually concerns whether the problem is painful enough, not whether it can be solved technically.
- Define what counts as success. Specifically, and before launch: for example, "10 of the 50 people on the list pay for the first month". Without it, any result can be read in your favour.
- Cut everything else. Login through five services, a reporting dashboard, an app for two platforms: if they don't help test that one assumption, they can wait.
I write more about running such a cycle step by step in the topic on the lean startup methodology, and about organising assumptions on a single page in the one on lean canvas.
How much an MVP costs and how long it takes
It depends on the type. A sign-up page or a concierge MVP can be ready in a few days and cost little. A working web app with one main feature, login and payments is usually a few weeks of work.
With me, an MVP of a web app with a narrow scope costs €1,900–9,300 at a fixed price and takes 2–6 weeks. I explain in detail where that range comes from and what the hidden costs are in the article MVP cost in 2026. If you want to get started, see how I build an MVP.
Frequently asked questions
Does an MVP have to be an app? No. If the most important question is "does anyone want this", a page, conversations and a service delivered by hand are often enough. It's worth building an app when you want to test whether people will use it regularly.
Can I show an MVP to customers if it's "unfinished"? Yes, as long as what it does, it does well. Early users forgive missing features, but they don't forgive it when the basic thing doesn't work.
What comes after an MVP? You measure what people did and decide: develop it, change direction or stop. I write about how to tell that a product has hit a real need in the topic on product-market fit.