What should an MVP include? How to scope the first version

An MVP, a minimum viable product, is the first working version of a new product. It is built to find out whether an idea holds before everything is built. What goes into it decides what you learn from it, and what it costs.

What is an MVP, and what is it not?

An MVP is working software that tests one idea with real users. Eric Ries defined it in 2009 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". The aim is learning, not a small product. In Ries's words: "MVP, despite the name, is not about creating minimal products."

It is not a prototype either. A prototype is clickable and has no database behind it: it shows how your software will look and how it is used. An MVP is working software with a database, used behind a login by the people you invite and measured against one number. Prototype, proof of concept or MVP? compares them side by side.

What must the first version include?

Enough to test your riskiest assumption with real users, and nothing the test does not need. In practice, that is the one task your idea depends on, working from start to finish, and the few things a real test needs around it: a database, a login and a way to measure.

• The core task, from start to finish. If your idea is that people will plan their week in your tool, they must be able to plan a whole week in it.
• A database. Real data, kept safely, so people can come back to it the next day.
• A login. The people you invite sign in. The first version is not public.
• A way to measure. The one number your test depends on, recorded as people use the software.
• Thorough testing. Tested from start to finish before your users get access.

Minimum scope, never minimum quality: the database and thorough testing are never cut. A first version that breaks tells you about its bugs, not about your idea.

What can wait?

Everything your test does not need. Features that make a product comfortable or complete can follow once you know the idea holds. Some work can even be done by hand at first, behind the scenes.

• Public pages and search engines. The first version is used behind a login by the people you invite.
• Payments, unless your assumption is about whether people will pay.
• Connections to other software, unless the test depends on them.
• More languages, roles and settings. Start with the users who matter for the test.
• Reports and exports beyond the one number you measure.
• Rare cases. Handle them by hand until you know they matter.

How do you decide what goes in?

Start from the assumption, not from a list of features. Write down the riskiest assumption, the one metric that tests it and the threshold it has to reach. Then take each feature and ask one question: does the test need it? If not, it waits.

1. Name the riskiest assumption. The belief that makes the rest pointless if it is wrong.
2. Choose one metric and its threshold, before any design or code.
3. Keep the features the test needs, and put the rest on a list for later.
4. See the design first. A prototype lets you try how the software will look and feel before it is built, and change it.

The Lean Startup describes the loop behind this: turn ideas into products, "measure how customers respond, and then learn whether to pivot or persevere". With us, after the design, we choose the features the first version needs, and the rest can wait.

An example: a first version with three features

Take an invented example. A founder wants to sell a planning tool to small cleaning companies. The riskiest assumption: owners will plan their week in the tool instead of on paper. The metric: how many of the invited companies plan their week in it, week after week, against a threshold set before the build.

The first version gets three features:

1. The owner plans the week: which cleaner goes to which address, and when.
2. Each cleaner sees the day on their phone and marks each visit as done.
3. The owner sees what was done, and what was missed.

Invoicing, payroll, a page for the end customers and more languages all wait. Each may matter later. None of them shows whether owners will plan their week in the tool.

ScoutCopilot, one of the many products we have built, began as a first version with exactly three features.

What happens after it launches?

It launches to the people you invite. They sign in and use it, and how they use it shows whether the threshold is reached. The result is clear: pivot, persevere or stop.

• Pivot: change course, and test the next assumption.
• Persevere: the idea holds, so build on it.
• Stop: the idea does not hold, and you know it before building everything.

If the answer is yes, the full product is built as custom web software, ready for everyday use. An MVP first, or the full build? helps you choose where to start. Our guide on what drives the cost of a SaaS MVP explains what decides the price, and MVP development shows how we build a first version.