How to scope an MVP: seven steps to decide what goes into your first release

An MVP is the smallest version of a product that can answer your most important open question with real users. The idea comes from the Lean Startup method: build something, measure how people respond, learn, and spend as little as possible on each round.

Building an MVP has become much cheaper with AI. Deciding what goes into it has not. Most first releases we are asked to look at are too big, not too small. These are the steps we use to scope one, whether we build it or you do.

1. Write down the one thing it has to prove

Start with a single sentence: the first release proves that a specific group of people will do a specific thing. For example, that small clinics will upload their documents instead of emailing them, or that freelancers will pay for an invoice reminder. If the sentence needs an "and", you probably have two products.

If you cannot write the sentence yet, that is the first piece of work. We explain why that thinking matters more than ever in AI made building cheap.

2. Pick one user and one job

Most products eventually serve several groups: customers, admins, partners, your own support team. The MVP serves one of them well. Choose the person whose behaviour your sentence depends on, and the one task they need to get done. Everyone else can be served by a spreadsheet, an email or a person on your team for now.

3. Draw the core flow end to end

Sketch the path from the moment someone arrives to the moment the job is done: sign up, enter what is needed, get the result, come back. Every screen on that path must work for real. Anything that is not on the path is a candidate for later. This one drawing settles more scope arguments than any feature list.

4. Sort every feature into four piles

• Build: the steps on the core flow that make your product different. This is where the budget goes.
• Do by hand: steps a person can handle behind the scenes at first, such as onboarding, matching or reports. If customers value the result, you automate it later with real data.
• Use a ready-made service: sign-in, payments, email and analytics. Proven providers are faster and usually safer than building your own.
• Later: settings, dashboards, roles, dark mode, integrations nobody has asked for yet. Write them down so they are not lost, and leave them out.

5. What never goes on the later pile

Small does not mean careless. As soon as real people put in real data, a few things belong in the first release, however small it is:

• Access rules that are tested: who can see which records.
• Payments handled by a payment provider, so card data never touches your app.
• A way to export and delete a user's data on request. In the EU this is a legal right under Article 17 of the GDPR.
• Backups, and one test that a restore actually works.
• Error reporting, so you hear about problems before your users tell you.
• The code repository, hosting, domain and store accounts in your own name.

If you already have a prototype from Lovable, Bolt or Cursor, our checklist from prototype to production goes through these points in more detail.

6. Decide how you will measure it before launch

Go back to your sentence and turn it into something you can count. How many of the people you invite complete the core flow? How many come back in the second week? How many pay, or ask how to pay? Agree on the number that would make you continue, change direction or stop, and add the tracking before launch, not after.

7. Fix the time and the budget, let the scope move

When something takes longer than planned, the tempting move is to extend the deadline. For an MVP it is usually better to keep the date and the budget, and cut from the later pile instead. A release that ships on time and proves one thing is worth more than a complete product that arrives after the money or the window is gone.

An example from our work

On WTE Companion, the groundwork started with one question: what does someone moving to Germany need to get done first? That question shaped the AI chat onboarding, where people describe their situation in their own words and are guided to the next step. The portals for service partners and support were built because the service only works when the people delivering it can do their part. The scope followed the job, not a feature list.

Signs your MVP is too big

• It serves more than one type of user equally.
• It has an admin area before it has its first ten users.
• Nobody can explain in one sentence what the launch will prove.
• The plan has no date on which you will decide what to do next.

A good MVP is not a smaller version of the full product. It is the fastest honest answer to your biggest question.

If you want help with the scoping or the build, our page for founders explains how we take a first version from idea to launch. Choosing a partner for it? These nine questions for an app agency are a good place to start.