Minimum viable product (MVP)
A minimum viable product is the smallest version of a product that can test whether an idea works, with real users doing real work. It is built to settle one commercial assumption rather than to be complete, and its scope is narrowed to a single user type and a single task.
Also known as: MVP, Minimum viable release, First releasable version
Last reviewed
Why an MVP matters
Building a full product before anyone has used it means betting the whole budget on assumptions nobody has tested. An MVP converts that single large bet into a small one: you build the least that will tell you whether people will actually change their behaviour, and you find out in weeks rather than after a year.
The commercial value is in the negative result as much as the positive one. A four-week answer of "no" is a good outcome; the same answer arrived at after two years of development is the most expensive thing a software project can produce.
How an MVP is scoped
The method that works is narrowing rather than halving. Pick one user type, one job they need done, and one path through that job — then build that path completely, for a real user with real data. Halving a wishlist instead produces a product with a bit of everything and nothing anyone can finish a task in.
You can also decide what to fake. Manual onboarding, a person reading submissions, a report assembled by hand: all reasonable, as long as the user's experience is genuine. Faking the back office is cheap and reversible. Faking what the user sees defeats the point.
MVP vs prototype vs proof of concept
All three reduce risk, and they answer different questions. A proof of concept asks whether something can be built at all, with no real users. A clickable prototype asks whether people understand the idea, using screens that look real but do nothing. An MVP asks whether people will use it and get value, which needs working software in real hands.
Run them in that order where the risks apply. Each is cheaper than the next, and skipping the cheap ones usually means discovering the same problems in built code.
When you need one
An MVP is the right step when the main uncertainty is behavioural rather than technical — will they use it, will they pay, does it actually save the time we think. In our projects most MVPs launch within 2 to 8 weeks, typically across 2 to 4 fixed two-week sprints, committed one at a time.
Before commissioning one, write down what result would make you continue, change course or stop. An MVP with no agreed pass mark always looks as though it needs a few more features.
Minimum viable product: common questions
An MVP is an experiment that happens to be shipped software: it exists to test an assumption and you intend to act on the result. A first version is simply the product at launch, scoped to a budget. Both are legitimate, but they justify different scope decisions and different success measures.
In our projects most aim to launch within 2 to 8 weeks, typically across 2 to 4 two-week sprints. Much longer than that and the scope has usually stopped being minimum. Because sprints are committed one at a time, the work can end as soon as you have learned enough.
No. Minimum refers to scope, not to craft. The one path it supports should work properly for real users with real data, because a broken experience tells you nothing about demand. What you cut is breadth — user types, features, edge cases — not reliability.
Want to talk about your project?
Tell us what you’re trying to achieve and we’ll map the fastest credible path.