What is an MVP? Definition, types and what MVP development means

What is an MVP?

MVP stands for minimum viable product. The term was popularized by Eric Ries, who defines it on his blog as that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. Read that sentence for what it measures. The unit is learning, not features.

Ries adds a caveat in the same post: MVP, despite the name, is not about creating minimal products. If your goal is only to scratch a clear itch or build something for a quick flip, he says you do not need an MVP at all, because the MVP imposes overhead. You have to learn something from the first version, which usually means talking to customers or reading metrics. Without that step you have only built a small product.

So an MVP has three parts. A hypothesis you want to test, such as “freelancers will pay to schedule tweets from a queue”. A thing people can react to, which may or may not be software. And a measurement that tells you whether the hypothesis held, such as sign-ups, pre-orders or repeat use. If any of the three is missing, you have a prototype, a demo or a launch, but not an MVP.

The Lean Startup site frames the MVP as the first step of its build-measure-learn loop: work out the problem, develop an MVP to begin learning as quickly as possible, then measure and decide whether to continue or change direction. For the planning work that comes before the MVP, see how to validate an app idea. For cutting a feature list down to one workflow, see how to scope an MVP.

What is the difference between an MVP, a prototype and a proof of concept?

People use these words loosely, and mixing them up causes bad plans. The definitions below are working definitions for deciding what to build. They are editorial, not an official standard.

The line that matters is who sees it and what they do. A prototype is judged on whether people understand it. An MVP is judged on whether they act: give an email, pay, come back. That is why a polished app that nobody uses is not a successful MVP, and an ugly spreadsheet that ten people pay for is.

What are the types of MVP?

There is no single correct format. The right type is the cheapest one that can still show whether people care. Eight formats cover most cases. The last column links to a documented example on the MVP examples page, where each story is sourced.

Most real MVPs mix two types. Buffer's founder ran a landing page and then a pricing step before writing the product. Airbnb's founders offered air mattresses to conference attendees with a simple website. You are not choosing a category from a menu; you are choosing the cheapest way to get a real reaction.

What is MVP development?

MVP development is the process of building the smallest thing that can test your riskiest assumption, then using the result to decide what to do next. Agencies sell it as a service, and the phrase has become a product category in itself. But the practice is the same whoever does it: pick one assumption, build the least that tests it, measure, decide.

That means the build often starts later than people expect. The first steps involve almost no code.

1. Name the riskiest assumption. Not the whole idea, the one belief that would sink it. “People will pay for this” is more dangerous than “we can build it”, for most ideas.
2. Choose the cheapest test from the table above. If a landing page can answer it, do not build an app. If you need working software to answer it, build one feature.
3. Set the success line before you start. Write down what result would make you continue, and what would make you stop. Numbers you pick after seeing the results tend to flatter the idea.
4. Build or run it. Time-box this. A first version that takes months is no longer minimal. Ries notes that his IMVU MVP took six months to bring to market, and that on another occasion two weeks spent on a feature nobody wanted was too long.
5. Show it to the right people. Ten people from your target group beat a thousand strangers.
6. Measure what they did, then decide. Continue, change the offer, or stop. Writing the decision down keeps you honest.

If the test says go, the scoping and build steps are covered in how to scope an MVP and how to build an app with Claude Code. For what building costs and how long it takes, see how much it costs to build an app and how long it takes to build an app. Those pages give ranges you can check against quotes, which this page does not.

How do you plan an MVP before you build it?

Fill in this card in one sitting. If you cannot complete a line, that is the line to work on first. It works for a landing page as well as for a working app.

Idea in one sentence: For [specific person] who [has this problem], [product] does [one thing].

Riskiest assumption: [The one belief that would sink the idea. Example: people will pay before it exists.]

MVP type: [landing page / video / concierge / Wizard of Oz / single feature / narrow audience / pre-sale / stitched tools]

What I will make: [Exactly what the person sees and does, in two sentences.]

Who I will show it to: [Number of people, and where I will find them. Name the places.]

What counts as success: [A behaviour and a number. Example: 8 of 30 visitors leave an email, 3 click the paid plan.]

What counts as failure: [The result that makes me stop or change the offer.]

Deadline: [A date, no more than a few weeks away.]

What I will not build: [Accounts, settings, payments, admin screens, anything the test does not need.]

Decision on [date]: [Continue / change / stop. Write this before the results arrive.]

The MVP Scope Planner turns a described user and goal into a first-version workflow, and the App Idea Validation Planner drafts the interview questions. Both are free and need no account.

How do you know whether an MVP worked?

An MVP worked if it changed what you will do next. A good result is not “people liked it”. It is a behaviour that costs the person something: their email, their time, their money, or their introduction to a colleague.

• Stronger signals: someone pays, someone returns without being asked, someone refers a colleague, someone complains when it is down.
• Weaker signals: compliments, likes, “I would definitely use that”, a large number of visitors who do nothing.
• Mixed results: if people sign up but nobody opens the second email, the promise works but the product does not. If they use it once and leave, the first impression works but the repeat reason does not.

Buffer is a documented small example. Its founder wrote that he treated people giving their email on a two-page test as his first validated learning, then added a pricing step to see which plan people clicked, and had his first paying customer within four days of launching the first working version. The details are in the MVP examples list.

An MVP result is also not proof of a lasting business. Whether people keep using the product is a later question, covered in product market fit.

What mistakes do people make with an MVP?

• Building before testing. The most common one. Months of work, then a first look from real users. A landing page or a manual version would have answered the question in days.
• Treating minimal as sloppy. The thing must work for the core job. A broken sign-up flow tests your code, not your idea.
• Testing with friends. They are polite and they are not your customer. Find people who have the problem and no reason to be kind.
• Choosing the success line afterwards. If you decide what “good” means after you see the numbers, any result passes.
• Adding features while waiting. Each extra feature makes the result harder to read. If it fails, you will not know which part failed.
• Skipping measurement. Ries notes that learning requires effort: talking to customers, metrics and analytics. An MVP with no way to see what people did is a small launch.

Where do you find an idea to test with an MVP?

If you already have an idea, fill in the card above. If you do not, browse the board for ideas other people posted and will not build. Each one has a generated build prompt you can paste into an AI coding tool, which makes a single-feature MVP a matter of hours rather than weeks. If you have an idea you will never test yourself, you can post it for a builder to try. Posting is free and needs no account.