Building a minimum viable product (MVP)

A minimum viable product (MVP) is the smallest version of a product that delivers real value to real users and tests your riskiest assumption. It is not a prototype, not a demo, and not a stripped-down v1 with every feature half built. The goal is validated learning, not a feature count.

The term comes from Frank Robinson around 2001, and Eric Ries made it famous in The Lean Startup (2011). Ries framed the MVP as the version of a product that lets a team collect the most validated learning about customers with the least effort. That word, learning, is the whole point. An MVP is an experiment wearing the clothes of a product.

What an MVP is not

Three terms get used interchangeably and shouldn't be. Getting them straight saves you from building the wrong thing.

• Prototype answers a design question. It can be a clickable mockup or a rough sketch, and it usually never leaves the building. You use it to test flows and feel before writing production code.
• Proof of concept (POC) answers a technical question: can this even be built? It is an internal spike that proves the hard part works, and customers rarely see it.
• MVP answers a market question: do people want this enough to use it and pay? It is a real, working product, however narrow, and it goes in front of actual users.

Here's the short version. A POC de-risks the tech, a prototype de-risks the design, and an MVP de-risks the demand. Skip the MVP and you can ship something that works perfectly and that nobody wants.

How to scope one

Scoping is the hard part, and it's where most MVPs quietly become full products. Four moves keep it honest.

1. Name the riskiest assumption. This is the belief that, if wrong, kills the product. Will people pay? Will they switch from what they use now? Build to test that first, before anything else.
2. Define one core flow. Pick the single path that proves the value, end to end. A user arrives, does the one thing that matters, and gets the payoff. Everything outside that path is a candidate for "later."
3. Cut ruthlessly. For each feature, ask one question: does the core flow work without it? If yes, cut it. Settings pages, admin dashboards, and edge-case handling almost always fail this test on day one.
4. Decide how you'll measure. Before you build, name the signal that tells you the assumption held. Without it, you'll ship and then argue about what the results meant.

A quick gut check: if you can't describe the MVP in one sentence that names the user, the action, and the payoff, you haven't cut enough yet.

Types of MVP

You don't always need to write much code to test an assumption. Some of the sharpest MVPs are mostly manual, which is the point when you're trying to learn fast and cheap.

• Concierge MVP. You deliver the service by hand, one customer at a time, with no automation behind it. The user gets a real outcome; you get to watch exactly where the value and the friction sit before you build any system.
• Wizard-of-Oz MVP. The front end looks fully automated, but a human is doing the work backstage. Users can't tell the difference, so you validate real demand without paying to build the engine first.
• Single-feature MVP. You ship one genuinely working feature and nothing else. This is the classic route for software products where the core flow needs to actually run in a user's hands.
• Landing-page MVP. A page describes the product and asks people to sign up or pre-order. It measures intent cheaply, though it tests interest rather than real usage, so treat the signal with care.

Fair warning: concierge and Wizard-of-Oz MVPs don't scale, and that's fine. They exist to buy you learning, not customers. You throw the scaffolding away once the assumption is answered.

How to measure success

An MVP without a hypothesis is just a small launch, and a small launch tells you almost nothing. Success is whether the riskiest assumption held, measured against the signal you named during scoping.

Pick a metric that maps to the actual belief. Testing demand? Watch conversion, activation, or retention, not vanity numbers like page views. Testing willingness to pay? Then charge money and count who does. A waitlist of 5,000 emails feels great and proves very little; ten people handing over a card proves quite a lot.

Set the threshold before launch, in plain language: "at least 30% of signups complete the core flow in week one." Deciding what counts as a pass after you see the data is how teams talk themselves into shipping something the market already rejected.

How long and how much an MVP should take

Think weeks to a few months, not a year. Most focused MVPs land in roughly 8 to 16 weeks with a small team, and the ones that don't are usually carrying too much scope. If the timeline creeps past six months, that's the signal to cut features, not to add engineers.

Cost tracks scope and team size, so the honest lever is the feature list. Every "while we're at it" feature pushes the date and the budget, and it delays the only thing that matters: real feedback from real users. Ship the narrow thing, learn, then decide what to fund next. For a deeper look at turning a validated MVP into a production system, custom software development engagements usually pick up right where the MVP hands off.

Common mistakes

• The bloated MVP. Scoping a full product and calling it minimal. If it takes a year to build, it isn't an MVP, whatever the roadmap says.
• The quality excuse. Treating "minimum" as permission to ship something broken. Scope is minimal; craft isn't. A narrow product can and should be polished, and for product-design reasons usually is.
• No learning goal. Shipping without a hypothesis, so you can't tell success from noise. This is the quiet killer, because the product looks done while teaching you nothing.
• Building for scale too early. Wiring up infrastructure for a million users before you have ten. That work is real, but it belongs after the demand is proven, not before.

After the MVP

A validated MVP is a foundation to harden and grow, whether that becomes a web platform, a mobile app, or a SaaS product. You fix the corners you deliberately skipped, shore up the core flow, and add the next feature the data actually asks for.

An invalidated one still did its job. It saved you the year you would have spent building the full thing, and that's the entire point of running the experiment small. Either way, the MVP was never the destination. It was the cheapest way to find out which direction to walk.