How to scope an MVP: what to build first and what to cut

To scope an MVP, name the riskiest assumption your business depends on, map the single user journey that tests it, and build only what that journey needs. Everything else gets cut, done by hand or bought off the shelf. A well-scoped MVP looks almost embarrassingly small on paper and still delivers real value to its first users.

Scope is the decision that sets your cost and your timeline, so it deserves more care than any line of code. Below is the six-step method I use with founders, worked through on one hypothetical product, with a one-page template at the end.

Step 1: start from your riskiest assumption

Every startup rests on a stack of assumptions. Most are safe. One or two could sink the business if they turn out to be wrong, and your MVP exists to test those, not to showcase the full vision.

Risky assumptions usually fall into one of five types:

• Demand: do people care enough about this problem to try something new?
• Behavior: will they change a habit, such as ordering online instead of by phone?
• Willingness to pay: will they pay, and enough to make the numbers work?
• Supply: in a marketplace, can you get enough of the other side?
• Feasibility: can the hard technical part, such as an AI feature, work well enough?

Write yours as a testable sentence with a success signal. Say you are building a platform where independent restaurants order produce directly from local farms:

We believe independent restaurants will order produce from local farms through a website every week instead of calling their usual supplier. We will know we are right if 10 of our first 30 restaurants order three weeks in a row.

That sentence makes repeat ordering the thing to test. Suddenly farm dashboards, delivery tracking and ratings look a lot less urgent. If you have not tested demand at all yet, do that first; here are cheap ways to validate an idea before any code.

Step 2: map the one core user journey

Next, write down the shortest path from a user arriving to that user getting the value you promised, in five to ten steps. Pick one primary user. In a marketplace, choose the side your assumption is about and serve the other side by hand.

For the produce platform, the journey belongs to the restaurant:

1. The chef or manager gets an invitation and creates an account.
2. They see this week's produce, prices and delivery day.
3. They build an order and submit it before the weekly cutoff.
4. They receive a confirmation by email.
5. The produce arrives on delivery day.
6. The following week, they order again.

Every step becomes a candidate feature. Anything that does not appear in the journey goes onto a list of things to question. The farms' side (listing produce, confirming quantities) can run on your phone and a shared spreadsheet for the first few months.

Step 3: list everything, then sort it with MoSCoW

Now write down every feature anyone has suggested, then sort each one into four buckets:

• Must have: without it, the core journey breaks or the assumption cannot be tested.
• Should have: important, but there is a workaround for the first release.
• Could have: nice, cheap, and only if time allows.
• Won't have (this time): explicitly out of version one. Writing it down stops it from sneaking back in.

Be strict with the Must column. A feature is not a must because a competitor has it or because launching without it feels embarrassing. It is a must only if the journey or the test fails without it. Here is how the produce platform might sort out:

Look at how much of the “product” is really you, a spreadsheet and some email. That is the point: it lets you test the assumption in weeks instead of months.

Step 4: apply the cut list

Much of what makes a product feel complete serves the business running it, not the user getting value. In version one, that work can almost always be faked, bought or postponed. These are the cuts I suggest most often:

• Admin panels become spreadsheets. A shared spreadsheet, Airtable or a simple database tool covers months of operations. Build the admin panel when manual work becomes the bottleneck.
• Automation becomes manual operations. Matching, approvals, refunds and onboarding can be done by a person. You learn which steps deserve automating, and simple glue between tools can come from Zapier.
• Custom features become off-the-shelf tools. Use existing services for payments (Stripe or similar), email, scheduling, chat and analytics.
• Two platforms become one. Launch on web or mobile, not both. Here is how to decide which platform should come first.
• Notifications become email. SMS, push and in-app notification centers can wait.
• Dashboards become exports. A weekly export and a spreadsheet chart beat a reporting module nobody has asked for yet.
• Roles become one or two. Fine-grained permission systems are expensive. Start with an admin and a user.
• Languages become one, unless your users genuinely need two from day one.

Some things never belong on the cut list: basic security, backups, the privacy and legal requirements of your market, analytics that measure your assumption, and the quality of the core journey itself. Small is fine; broken is not. If you are wondering whether a no-code tool could carry the whole first version, weigh no-code against custom development before you decide.

Step 5: write acceptance criteria for every must-have

A feature name like “ordering” means one thing to you and another to a developer. Acceptance criteria close the gap: short, testable statements of what must be true for a feature to count as done. Plain English is fine. For the produce platform's ordering feature:

• A signed-in restaurant can add any item on this week's list to an order and change quantities before submitting.
• Orders cannot be submitted after the weekly cutoff, and the page says so clearly.
• After submitting, the restaurant and your operations inbox each receive an email with the full order within a few minutes.
• A restaurant can see its past orders with dates and totals.

Criteria like these make estimates more accurate, give testers something to check, and turn arguments about whether something is finished into a quick look at a list. If you will be working with the developers day to day, here is more on managing developers without a technical background.

Step 6: fit the whole scope on one page

Pull everything into a single page. If it does not fit, the MVP is probably still too big. Here is a template you can copy:

1. Problem: two sentences on who has it and how they cope today.
2. Primary user: the one person version one serves.
3. Riskiest assumption and success signal: your testable sentence from step 1.
4. Core journey: the five to ten steps from step 2.
5. Must-haves: each with its acceptance criteria.
6. Manual workarounds: what will be done by hand, and by whom.
7. Out of scope: the Won't list, in writing.
8. Platform and integrations: where it runs and what it connects to.
9. Data and compliance: personal data, payments, health or financial information, and where data must be stored.
10. Constraints: budget range and target launch date.
11. Success metrics: what you will measure from the first day.
12. Open questions: what you still need to find out, and by when.

This page is also the best brief you can hand anyone who is quoting the work. A clear scope is what turns a vague guess into a believable estimate of what the build will cost and how long it will take.

Common mistakes when you scope an MVP

• Scoping for investors instead of users. Features that make a pitch deck look complete rarely help you learn faster.
• Copying a competitor's feature list. They built those features over years, for customers they already have.
• Building for scale you do not have. Designing for a million users before you have a hundred adds cost without removing any real risk.
• Building both sides of a marketplace in full. Serve the side your assumption is about with software, and the other side by hand.
• Using “minimum” as an excuse for sloppy. The core journey should work every time and feel trustworthy.
• Letting the scope grow during the build. New ideas will keep coming. Swap rather than add: anything new that goes in pushes something of similar size out, and the rest goes on a list for version two.

The bottom line

Scoping an MVP is mostly the discipline of saying “not yet.” Start from the assumption that could sink you, build the one journey that tests it, handle everything else by hand or with existing tools, and write down what you are deliberately leaving out. Then launch, watch what users actually do, and let that decide what goes into version two.