Article
How to scope an MVP so a developer can estimate it
By Adil Soukaini
, 6 min read
To scope an MVP, write down the one problem you are testing and the one user who has it, map the single flow that takes that user from arrival to the moment they get value, and put every other idea into Must, Should, Could or Won't have. Then write each Must-have as a short user story with acceptance criteria. That document is what lets a developer give you an estimate you can trust.
Below is the process step by step, with a template you can copy.
Why scope matters more than the feature list
The Agile Alliance, quoting Eric Ries, describes an MVP as the version of a product that lets a team "collect the maximum amount of validated learning about customers with the least effort". The word that matters is learning. A scope that tries to cover every user and every case delays the moment you find out whether anyone wants the product.
That moment is expensive to postpone. In CB Insights' 2026 review of 431 VC-backed companies that shut down, 43% cited poor product-market fit and 70% ran out of capital. A tight scope is how you spend less before you know.
Step 1: Write the problem and the bet in three sentences
Before any feature, write:
- Who has the problem (be specific: "independent cleaners in Casablanca who take bookings by WhatsApp", not "service providers").
- What the problem costs them today (time, missed bookings, money).
- What you need to learn: the assumption that, if wrong, kills the idea. For example: "Cleaners will accept bookings through an app instead of WhatsApp."
Every feature you add later has to help answer sentence 3. If it doesn't, it waits.
Step 2: Map the core flow
The core flow is the shortest path from "user arrives" to "user gets the value". Write it as numbered steps, one line each. For a booking product it might be:
- Customer opens the link and sees available time slots.
- Customer picks a slot and enters address and phone number.
- Cleaner gets a notification and accepts.
- Customer gets a confirmation.
Four steps. Accounts, ratings, payments and chat are not in it. They may come next, but the flow works without them, and you can watch whether people complete it.
If you have two user types, map both sides of the same flow, and check whether one side can be handled manually at first. A founder confirming bookings by hand for the first weeks is a legitimate MVP.
Step 3: Sort everything with MoSCoW
Now list every feature idea, then sort each into one of four buckets. The definitions come from the DSDM framework maintained by the Agile Business Consortium:
- Must have: without it there is no point launching.
- Should have: important but not vital; the product is still viable without it, perhaps with a workaround.
- Could have: desirable, less impact if left out.
- Won't have this time: agreed to be out of this release.
The same guidance recommends keeping Must-haves to no more than 60% of the effort, with around 20% in Could-haves as contingency. If your Must list fills the whole budget, there is no room for the surprises every project has. Cut until it doesn't.
The Won't list is as useful as the Must list. Writing "no in-app chat in v1" settles the question for the whole team and stops it creeping back in.
Step 4: Fix the time, not the features
Basecamp's Shape Up method makes a distinction founders find useful: "Estimates start with a design and end with a number. Appetites start with a number and end with a design." Decide how much time the MVP is worth to you (six weeks? ten?) and shape the scope to fit. Shape Up calls this "fixed time, variable scope".
In practice: give your developer the appetite along with the Must list, and ask what fits. That conversation produces better scopes than asking for a quote on a wish list. It also pairs well with weekly releases, where you see progress against the appetite every week.
Step 5: What to leave out of version one
These are the features most often added "because every app has them":
- Social login with several providers (one method is enough).
- User settings and notification preferences.
- Admin dashboards and analytics (use an analytics tool and the database admin).
- Ratings and reviews, before there are enough transactions to rate.
- In-app chat (email, phone or WhatsApp links work at first).
- A second language, unless your first market needs it.
- Native apps for both stores, when a responsive web app would test the same assumption.
Leaving these out is not cutting corners on quality. The parts you do build should be solid: the Agile Alliance lists poor quality as a classic MVP mistake, because a broken product can't tell you whether the idea works. Shortcuts in the code itself create technical debt that you pay for later, and AI-generated prototypes have their own limits, covered in what vibe coding can and can't do for an MVP.
Step 6: Write it so a developer can estimate it
A developer can only estimate what is specific. For each Must-have, write a user story and its acceptance criteria.
User stories that pass the INVEST test
The INVEST checklist, which the Agile Alliance attributes to Bill Wake (2003), says a good story is Independent, Negotiable, Valuable, Estimable, Small and Testable. "Estimable" and "Small" are the ones that decide whether you get a reliable number.
As a customer, I want to pick an available time slot, so that I can book a cleaning without calling.
Acceptance criteria as examples
The Agile Alliance describes an acceptance test as "a formal description of the behavior of a software product, generally expressed as an example or a usage scenario". Write two to five per story:
- Slots already booked are not shown.
- A slot less than two hours away cannot be booked.
- After booking, the customer sees a confirmation with date, time and address.
Keep them in business language. The same page warns that overly technical acceptance tests become hard for non-developers to read and maintain.
The rest of the scope document
- Platforms: web, iOS, Android; which browsers and devices.
- Users and volume: expected users in the first three months.
- Integrations: payment provider, maps, email, SMS; with links to their docs.
- Content and languages: who writes the copy, in which languages.
- What exists already: designs, brand, domain, data to import.
- Won't-have list.
- Open questions: things you don't know yet. Listing them is better than hiding them.
With this, compare estimates line by line, and use them to sanity-check the total against what an MVP typically costs. It also tells you which contract fits: a well-defined small scope can be fixed-price; a scope with many open questions suits time-and-materials or a retainer (see fixed price vs time and materials vs retainer).
Frequently asked questions
How many features should an MVP have?
As few as it takes to complete the core flow and test your main assumption. Count the steps in the flow rather than the features; most good MVPs fit in one flow of four to eight steps.
What is the difference between an MVP and a prototype?
A prototype shows how something might work, often without real data. An MVP is used by real users in real conditions, so you can measure what they do.
Who should write the MVP scope, the founder or the developer?
The founder writes the problem, the flow and the priorities; the developer challenges them, adds technical constraints and estimates. Plan one or two rounds between you.
Should I write a full specification document?
No. A few pages with the problem, the core flow, prioritised user stories with acceptance criteria and a Won't list is enough to estimate and start.
Sources
- Minimum Viable Product (MVP), Agile Alliance, accessed October 2026
- Top reasons startups fail, CB Insights, March 2026
- MoSCoW Prioritisation (DSDM Project Framework), Agile Business Consortium, accessed October 2026
- Shape Up, chapter 3: Set Boundaries, Basecamp, accessed October 2026
- INVEST, Agile Alliance, accessed October 2026
- Acceptance Testing, Agile Alliance, accessed October 2026
