What an MVP Really Is: How to Scope Your First Version (2026)
What a minimum viable product is and isn’t, the main types of MVP, and a step-by-step method for cutting your idea down to a first version you can ship in weeks.
Key Takeaways
- An MVP is a learning tool, not a small product. Its purpose is to test your riskiest assumption with real people as cheaply and quickly as possible.
- Start from the assumption, not the feature list. Write down what must be true for the idea to work, pick the riskiest, and build only what tests it.
- Manual work behind the scenes is allowed. Many successful first versions had a person doing by hand what software would do later.
- “Viable” still means it solves the problem. Cut features, not quality on the one thing it does. A broken core flow teaches you nothing.
- Time-box it. Pick a ship date in weeks, then cut scope to fit. When the date and the scope collide, the scope loses.
Quick-Start Prioritization Framework
| Step | What you do | Output |
|---|---|---|
| 1. List assumptions | Write everything that must be true for the idea to work | 8–15 assumptions |
| 2. Rank by risk | Mark which are most uncertain and most fatal if wrong | The top 1–2 risks |
| 3. Pick an MVP type | Choose the cheapest test that gives a real answer | Concierge, single-feature, landing page, etc. |
| 4. Cut the feature list | Keep only what the test needs | A main flow of 5–8 steps |
| 5. Set a ship date and a success signal | Time-box in weeks; define what counts as a yes | A date and one measurable sign |
“Minimum viable product” is one of the most used and least agreed-on phrases in startups. Some people mean a rough prototype. Some mean a polished first release. Some mean a landing page with no product behind it. The confusion matters, because it leads first-time founders to spend six months on a version one that should have taken three weeks. This guide explains what an MVP is for, the different shapes it can take, and a practical way to cut your idea down to one, with a worked example.
What an MVP is (and what it isn’t)
Eric Ries popularised the term in The Lean Startup. His Build-Measure-Learn loop starts from the idea that the fundamental activity of a startup is to turn ideas into products, measure how customers respond, and then decide whether to change direction or keep going. The MVP is the first turn of that loop: the least you can build to start learning as quickly as possible.
Michael Seibel of Y Combinator puts it in practical terms: build the smallest product that lets you start offering your service to users, because you have no idea yet whether your complete solution will work. He points to Airbnb’s first version, which had almost no features and was built in under a month.
An MVP is not
- A smaller copy of your dream product with every feature at 30% quality.
- A demo or mock-up nobody can actually use to solve their problem.
- Version one of a roadmap you have already committed to.
- Something you are embarrassed to show anyone. It should be small, not hidden.
The two words that get forgotten
“Minimum” gets all the attention. “Viable” matters as much: the product has to actually do the one job for real people. A food-delivery MVP that takes orders but never delivers isn’t viable; one that takes orders by form and has the founder drive the food over is.
The main types of MVP
There is no single MVP shape. Pick the type that answers your riskiest question with the least building.
| Type | What it is | Tests | Building required |
|---|---|---|---|
| Landing page (smoke test) | A page describing the product with a sign-up or pre-order button | Whether people want it enough to act | Very little |
| Concierge | You deliver the service by hand to a few customers, openly | Whether the outcome is valuable and what the steps really are | Almost none |
| Wizard of Oz | Looks like software to the user; a person does the work behind the scenes | Whether people use it the way you expect | A front end only |
| Single-feature app | A real app that does exactly one job well | Whether people come back to use it | Small |
| Piecemeal | Existing tools stitched together (forms, spreadsheets, email) | Whether the workflow works before you automate it | Little |
| Pre-sale | Customers pay before the product exists | Willingness to pay | A checkout link and a promise |
Choosing between them
If your biggest doubt is “does anyone want this?”, a landing page or pre-sale answers it fastest. If it is “will this actually help them?”, a concierge MVP teaches you most, because you see every step. If it is “will they use software for this regularly?”, you need a single-feature app, because only real use over weeks answers that.
Why most founders now build a single-feature app
AI app builders have made a small working app much cheaper to produce than it was a few years ago. That shifts the balance: if you can build a single-feature app in a weekend, it often teaches you more than a landing page, because people can actually use it. The scoping discipline below matters more, not less, when building is cheap, because adding features is so easy.
How to scope your MVP in five steps
This is a method you can do in an afternoon with a document and an honest friend.
1. Write down your assumptions
List everything that has to be true for the idea to work. Include assumptions about the problem (people have it, it hurts enough), the user (you can reach them), the solution (your approach fixes it), behaviour (they’ll switch from their current workaround) and money (someone will pay). Aim for 8 to 15.
2. Rank them by risk
For each assumption, ask two questions: how sure am I, based on evidence rather than hope? And if this is wrong, does the whole idea fail? The assumptions that are both uncertain and fatal are what your MVP must test. Everything else can wait.
3. Choose the cheapest real test
Match the top risk to an MVP type from the table. Ask: what is the least I can build and still get a real answer from real people? A real answer is behaviour (they signed up, used it twice, paid), not opinion (they said it sounds cool).
4. Cut the feature list to the test
Write your full wish list, then go through it with one question per item: is this needed to run the test? Sign-in is usually needed. Settings, profiles, notifications preferences, admin dashboards, dark mode, and integrations usually are not. Move every “no” to a “later” list so you don’t lose the idea.
5. Set a ship date and a success signal
Choose a date in weeks, not months, and keep it. Then write the result that counts as a yes: “15 of the first 30 people who sign up use it in their second week.” Writing it down first stops you moving the goalposts after launch.
A worked example: a meal planner for busy parents
Here is the method applied to a typical idea: an app that plans a week of family dinners, builds the shopping list, and adapts to kids’ preferences.
The wish list
Weekly meal plans, recipe library, picky-eater filters, automatic shopping list, grocery delivery integration, leftovers tracking, nutrition scores, family member profiles, sharing with a partner, a phone app, reminders, cost estimates.
Assumptions, ranked
| Assumption | How sure? | Fatal if wrong? |
|---|---|---|
| Parents find weekly dinner planning stressful | Fairly sure (own experience, friends) | Yes |
| They will follow a plan someone else made | Unsure | Yes |
| A shopping list from the plan saves real time | Unsure | Partly |
| They want nutrition scores | Unsure | No |
| They’d pay for it | Unsure | Yes, but later |
| Grocery delivery integration is needed | Unsure | No |
The MVP
The riskiest assumption is the second: will parents actually cook from a plan they didn’t write? The cheapest real test is a concierge MVP followed by a single-feature app.
Weeks one and two (concierge): ten parents fill in a short form about their family’s likes and dislikes; the founder emails each a five-dinner plan and a shopping list every Sunday, and asks on Friday which dinners they actually made.
Weeks three to five (single-feature app): parents sign in, set preferences, get a weekly plan with swap buttons and a generated shopping list. Nothing else.
Success signal: at least half of active parents cook three or more planned dinners in week two of using the app.
What got cut, and why
Grocery delivery, nutrition scores, family profiles, leftovers, cost estimates, the phone app and partner sharing all moved to “later”. None of them tests whether parents follow a plan. If they don’t, none of those features matter; if they do, users will tell you which to build first.
How much is too little?
Founders worry about shipping something too thin. The risk is real but narrower than it feels.
Signs your MVP is too small
- People can’t complete the core job without your help, and you aren’t deliberately running a concierge test.
- The test can only produce opinions, not behaviour.
- It has a security or privacy gap: people can see each other’s data.
- It loses or corrupts what people put into it.
Signs it is too big
- It has been in progress for more than two months without a real user.
- It serves two or more user types equally.
- It contains features that test assumptions you already ranked as low risk.
- You can’t say which one assumption it is testing.
After the MVP: reading the result
An MVP produces one of three results. Decide in advance what you’ll do with each.
A clear yes
People use it, come back and ask for more. Keep the same users close, fix what slows them down, and add the next feature they keep asking for. Resist adding the whole “later” list.
A clear no
Nobody completes the main action, or nobody returns. That is a successful MVP: it saved you months. Go back to the conversations and find out why before changing the product.
A muddy middle
Some people use it a little. This is the most common result. Look for the subgroup that uses it most and ask what they have in common. Often the next version is the same product for a narrower user.
Common mistakes
These are the scoping errors that most often turn a three-week MVP into a six-month project.
- Building for every possible user instead of one specific type.
- Polishing design, branding and onboarding before anyone has used the core flow.
- Treating compliments (“I’d totally use this”) as validation instead of behaviour.
- Adding payment, admin tools and settings before the core action works.
- Never setting a success signal, so every result looks encouraging.
- Treating the MVP as version one of the final codebase and over-engineering it.
- Calling something an MVP to excuse a broken core flow.
If you’d rather not build it yourself
If you’d rather not wire up an MVP by hand, an AI app builder can turn a tightly scoped feature list into a working web app. Floot, which publishes this site, builds single-feature apps like the meal planner above, with sign-in, a database and email included, from a plain-English description.
Frequently Asked Questions
What does MVP stand for?
Minimum viable product: the smallest version of a product that real people can use to solve their problem, built to learn whether the idea works before investing more.
How long should it take to build an MVP?
Weeks, not months. Michael Seibel cites Airbnb’s first version as built in under a month. With today’s AI builders, a single-feature MVP can take a weekend to a few weeks. If yours is past two months without a real user, it is probably too big.
What is the difference between an MVP and a prototype?
A prototype shows what something could look like or how it might work, often without real data. An MVP is used by real people to do a real task, so it produces evidence about behaviour.
Can an MVP be done without code?
Yes. Concierge, landing-page, piecemeal and pre-sale MVPs need little or no code, and AI and no-code builders can produce a working single-feature app without programming.
Should my MVP charge money?
Only if willingness to pay is your riskiest assumption. Otherwise, test that people use and return to it first, then test pricing. Asking for payment early is a strong signal, but it adds setup that can delay the core test.
How do I know if my MVP worked?
Compare the result with the success signal you wrote before launch, based on behaviour such as repeated use. If you didn’t set one, set it now for the next round.
Sources
- The Lean Startup, Principles (Eric Ries) https://theleanstartup.com/principles
- Y Combinator, One Order of Operations for Starting a Startup (Michael Seibel), 2018 https://www.ycombinator.com/blog/one-order-of-operations-for-starting-a-startup
- Paul Graham, Do Things That Don’t Scale, 2013 https://paulgraham.com/ds.html
- Rob Fitzpatrick, The Mom Test (book site) https://www.momtestbook.com/