What is MVP (Minimum Viable Product)?
Definition
A minimum viable product (MVP) is the smallest working version of a product that lets a team test its riskiest assumption with real users. Its goal is not a finished product but validated learning with the least effort: do people actually have this problem, and will they spend time or money on this solution? The idea was popularised by Eric Ries's Lean Startup method.
Also known as: minimum viable product, MVP, first release
An experiment, not a cheap version
Treating an MVP as “version one, but cheaper” misses the point. In the Lean Startup framing it is an experiment designed to test a hypothesis, such as “independent gyms will pay monthly for automated class reminders”. The loop is build the smallest thing, measure what real users actually do, then learn: persevere, pivot or stop.
So the first question for an MVP is not which features to build, but which assumption would be most expensive to get wrong. Everything in scope should serve testing that assumption quickly and cheaply.
Prototype, proof of concept or MVP?
| Question it answers | Who uses it | Working software? | |
|---|---|---|---|
| Prototype | Does the flow make sense? Is the design right? | Usability test participants, the team | Often not; a clickable mock-up is enough |
| Proof of concept | Can it be built at all? | Developers | Partly; only the risky technical piece |
| MVP | Will real users adopt it and find it valuable? | Real customers | Yes: narrow, but genuinely working |
They often run in sequence: a proof of concept retires the technical risk, a prototype tests the flow, then the MVP meets the market.
Cutting scope without cutting corners
- One audience, one job: not “restaurants” but “single-location restaurants that do delivery”; not “inventory management” but “weekly stock count and shortage list”.
- Manual behind the curtain: invoicing, reporting or admin tools can start as things the team does by hand. Users see the front end; automation comes once the demand is proven.
- Buy what isn't core: payments, email delivery and scheduling can come from off-the-shelf SaaS products, so custom development goes only into what makes the product different.
Minimum does not mean sloppy. The scope can be tiny, but what ships has to work; an MVP that crashes measures the execution, not the idea. And for anything handling personal data, authentication, access control, backups and data protection obligations (GDPR, or KVKK in Turkey) are not optional extras to trim.
Define success before launch
Write the success criteria down before the MVP goes live, or any outcome can be rationalised as “promising” afterwards. Prefer behavioural measures to vanity metrics like sign-ups or page views:
- Activation: what share of sign-ups completed the core task at least once in their first week?
- Retention: how many are still coming back in week four?
- Money or commitment: is there a real conversion, such as a paid upgrade or a pre-order?
Talk to users as well. Analytics will tell you that people dropped off; interviews are usually how you find out why.
After the MVP
Once the hypothesis holds, the quickly written MVP code can become a serious source of technical debt. That is fine if it was taken on deliberately; what matters is deciding consciously, before scaling, which parts to keep and which to rebuild. This is the point where investing in a durable architecture, a proper data model and custom software starts to pay off.