How to Scope an MVP: A Founder's Checklist

Here is how to scope an MVP: write down one user, one job that user needs done, and one number that tells you it worked. Then list every feature, estimate the effort, and keep only the work that the job cannot happen without. Draw a cut line and write a “not in v1” list. Of the whole MVP development process, scoping is the step that decides your budget and your timeline. It is also the step most founders rush.

Scope is a list of decisions, not a list of features. This article gives you five steps, an example table and a checklist you can copy today.

What an MVP is for

Eric Ries defined the minimum viable product as the version of a product that lets a team collect the maximum amount of validated learning with the least effort. The key word is learning. Your MVP exists to answer a question about your market. It does not exist to show every idea you have.

If you want the longer version, with how an MVP differs from a prototype, read what MVP development means.

Step 1: Write down one user, one job and one metric

Before you list a single feature, write three lines:

1. User: the one type of person who pays or uses it first. “Independent physiotherapists in the Netherlands” is a user. “Healthcare professionals” is a market.
2. Job: the task they need done, in their words. “Fill empty appointment slots without phoning patients.”
3. Metric: the number that shows the job got done. “Clinics fill at least some cancelled slots through the tool in the first month.”

If you cannot write these three lines, you are still in discovery. Talk to more users first. That is cheaper than any sprint. A marketplace has two sides, so scope one job per side and no more.

Step 2: List every feature, then sort by effort

Now write down every feature you can think of. Do not filter yet. Put the list in a spreadsheet with four columns: feature, why the user needs it, rough effort (small, medium, large), and priority.

For priority, use MoSCoW: Must have, Should have, Could have, Won’t have this time. Most guides stop there. The original guidance from the Agile Business Consortium adds a rule most founders never hear. It recommends no more than about 60% Must Have effort in a timeframe, with around 20% of effort in Could Haves as contingency.

Note the word effort. Ten small Must Haves can cost less than one large one. If your Must Haves fill the whole budget, you have no room for surprises, and you will cut features under pressure instead of by choice.

My rule for a Must Have is simple. If you remove it, can the user still do the job end to end, even badly? If yes, it is not a Must.

Step 3: Replace features with manual work

Many features in a first version can be a person instead of code. Paul Graham describes how early startups did things by hand that did not scale to get their first users. The same idea works for scope.

Examples of manual replacements:

• Onboarding: you set up each account on a video call instead of building a self-serve wizard.
• Reports: you export the data and send a spreadsheet each week instead of building dashboards.
• Matching or approval: you review each request in an admin screen instead of writing rules.
• Billing: you send invoices from your accounting tool instead of building plans, trials and upgrades.

Manual work is slow, but it teaches you what to automate. Keep one limit: do not fake the core job. If your product promises instant matching, a person matching in 24 hours does not test the promise.

Step 4: Scope the parts nobody demos

This is where quotes split apart. A founder lists the visible features, and each agency guesses the rest. One assumes basic email login. Another assumes single sign-on, roles and audit logs. Both quotes are “for the same MVP.”

Decide these items yourself and write them in the scope:

• Sign-in: email and password, magic link, or Google/Microsoft sign-in. Pick one for v1.
• Roles: how many types of user, and what each one can see.
• Payments: none, invoices, or card payments through a provider. Which countries and payment methods.
• Email: which transactional emails the system sends (welcome, reset, receipt).
• Admin: only what you need to run the business day to day. An admin panel is easy to over-scope.
• Analytics and error tracking: which events you will measure to check your metric from Step 1.
• Data protection: what personal data you store, where, and for how long. Under the GDPR, data protection by design is a legal duty for controllers, and you must limit collection to what each purpose needs. It costs far less to decide this before the build than to change it after.
• Platforms: web only, or also iOS and Android. A responsive web app covers most first versions. Build a native app in v1 only if the job needs the phone itself, for example the camera, location in the background or push notifications.
• Hosting and backups: where it runs, who owns the accounts, and how you restore data.

None of these items show up in a demo. All of them show up in the invoice. For the technology side of these choices, see our guide to a SaaS MVP tech stack.

Step 5: Draw the cut line and write the “not in v1” list

Sort your spreadsheet so the Musts are on top. Add the effort. If the Musts go above roughly 60% of your time or budget, move the weakest ones down until they fit. Draw a line. Everything above the line ships in v1.

Then copy everything below the line into a separate list called “Not in v1.” For each item, write the trigger that would move it up. “Team accounts: build when three paying clinics ask for a second login.” The list also protects you during the build. When a new idea comes up, it goes on the list first.

Example: a must / should / later table

This is an invented example to show the format, not a client project. The product is a tool that lets physiotherapy clinics offer cancelled slots to patients on a waiting list.

Notice what is missing from the Musts: no calendar sync, no payments, no app. The tool can still prove or disprove the one question that matters. Will clinics and patients use a waiting list to fill cancelled slots?

How to scope an MVP: the checklist

Copy this list into your scope document. Every line needs an answer before you ask for a quote.

• One user type (or one per side for a marketplace) written in one sentence
• One job, in the user’s own words
• One success metric, with a time frame
• Full feature list with a reason per feature
• Effort per feature (S/M/L is enough)
• MoSCoW priority per feature, with Musts at or below about 60% of effort
• Manual replacements noted for non-core features
• Sign-in method and user roles decided
• Payments decided (none, invoice or card, which methods)
• Transactional emails listed
• Admin needs limited to running the business
• Events to measure for the success metric
• Personal data listed, with where it is stored and for how long
• Platforms decided (web, iOS, Android)
• Ownership of code, domain and cloud accounts decided
• “Not in v1” list with a trigger per item
• A date to review results after launch

How to use your scope to get comparable quotes

Send the same scope document to every agency or freelancer you talk to. Ask each one to price the Musts only, and to list every assumption they made. Then compare the assumptions, not just the totals. A low quote often hides a short list of assumptions. A high quote may include items you already cut.

Ask each vendor which Must they would move down, and why. A good partner pushes back on your scope. If nobody challenges anything, they have not read it closely.

If you want a second opinion before you sign, an independent review of a scope or quote costs much less than a build that goes in the wrong direction.

FAQ

How many features should an MVP have?

There is no fixed number. Count effort instead, and keep Must Haves at or below about 60% of your time and budget.

How long should MVP scoping take?

It depends on how much discovery you have already done. If you can write the user, job and metric today, a focused scope document takes days, not weeks. If you cannot, spend the time on user conversations first.

Should my MVP be a mobile app or a web app?

Start with a responsive web app unless the job needs phone features such as the camera, background location or push notifications. One web code base is faster to change while you are still learning.

What is the difference between an MVP and a prototype?

A prototype shows how the product could work, often with no real data or backend. An MVP is a working product that real users use, so you can measure the metric from Step 1.

How do I stop scope creep during the build?

Use the “not in v1” list as the inbox for every new idea. If something truly must move into v1, something of the same effort moves out. Agree that swap rule with your build team before the first sprint, not in the middle of one.

What do I do with features I cut?

Put each one on the “not in v1” list with a trigger. Review the list after launch, with real usage data in hand. Many cut features never come back, and that is a good result.

Next step

If you have a scope, or half of one, and want it built by senior engineers with a fixed scope, see how our MVP development works. Or send us your scope and we will tell you which Musts we would move down and why.