How to scope an MVP in one week: a day-by-day method
A five-day method to scope an MVP: one problem sentence, one workflow, a cut feature list, screens and data, then a budget check.
By Sohail Hussain6 November 20266 min read
You can scope an MVP in five working days by spending one day on each of five questions: what problem, for whom, does the first version solve; what is the one workflow that solves it; which features does that workflow need; what screens and data does it take; and does the result fit the budget and timeline. At the end you have a one-page scope, a list of what is out, and a success target you set before a line of code is written.
A week sounds short. It is enough because scoping is mostly cutting, and cutting is faster when the rules are fixed in advance. Teams that take a month to scope are usually negotiating which features to keep, not discovering new ones. If you have not yet decided whether you need software at all, read what an MVP is first; it covers the cheaper tests that come before a build.
What do you need before day one?
Three inputs. Without them the week turns into a debate.
- Notes from customer conversations. Ideally fifteen or more, as described in our guide on how to build a SaaS product. You will check every scoping decision against what customers said.
- A budget and a date. Not a precise number, but a range and a deadline that is real. Scope expands to fill an open budget.
- One person who can say no. Usually the founder. Scoping by committee keeps everything.
This is also the shape of the first phase of our web app and SaaS development projects: a week of scoping that ends in a fixed list, before design and build are priced.
Day 1: what problem, and what is the one job?
Write two sentences. The first names the customer and the pain: "Operations managers at logistics firms with 20 to 100 drivers spend four hours a week reconciling timesheets against job records." The second names the one job the first version does: "Upload the week's timesheets and job export, and get a list of mismatches to approve or fix."
If you cannot get to a single job, you have two products. Pick the one where customers described the pain most sharply and where they already spend money or time on it. The other can be version two.
Spend the rest of the day on who the first customer is not. Larger firms with an ERP, firms in other countries, firms with a different payroll system. Every exclusion you write now removes features later.
Day 2: what does the core workflow look like, step by step?
Map the job from the moment a customer signs up to the moment they have the result. Write each step on its own line, including steps that happen outside the product: exporting a file from another system, emailing a colleague, approving something on a phone.
For the timesheet example, that might be: sign up, create the company, upload timesheets, upload the job export, see the mismatch list, approve or correct each one, export the corrected file, pay. Eight steps.
Now mark each step as manual or automated in version one. Some steps can stay manual for months. Creating the company account by hand for the first ten customers takes you ten minutes and saves a week of onboarding screens. The result of day two is a short list of steps the product must automate, which is far shorter than the list of steps that exist.
Day 3: which features make the cut?
Write down every feature anyone has mentioned: from the founder, investors, customers, competitors' websites. Expect forty to a hundred items. Then sort each one into three columns with a single question: can the first paying customer get the result from day one without it?
| Feature | Decision | Why |
|---|---|---|
| Email login | Now | No account, no product |
| Upload timesheet CSV | Now | The core workflow starts here |
| Mismatch list with approve and fix | Now | This is the one job |
| Stripe subscription with trial | Now | The MVP must test whether people pay |
| Admin view of accounts | Now | You need to support customers without database access |
| Team invitations | Later | One manager per firm at first |
| Direct payroll integration | Later | CSV export works until there are customers to justify it |
| Mobile app | Later | Managers do this at a desk |
| Custom report builder | Never, for now | No customer asked for it |
Keep "later" honest by writing why. When someone asks for a feature in month three, the reason tells you whether anything has changed. Billing settings, invoices and card updates are a good example of features you do not build at all: Stripe's customer portal handles them for you.
Day 4: what screens and data does it need?
Sketch every screen the "now" list needs, roughly, on paper or in Figma. A well-scoped MVP has five to twelve screens. Count them. If you have more than fifteen, go back to day three.
Then list the main records the product stores and how they relate. For the example: company, user, timesheet upload, job record, mismatch, subscription. Six. Draw the lines between them. This is the start of the data model, and it is where hidden scope shows up: if a mismatch can belong to two uploads, or a user can belong to two companies, you have found a decision that changes the build. Make it now, while it is cheap.
Two decisions belong here even though they feel technical, because they are expensive to change later: how customers' data is separated from each other's, covered in multi-tenant SaaS architecture, and whether billing is per account or per seat.
Day 5: does it fit, and how will you know it worked?
Get an estimate for the screens and data you have, from the team that will build it. Two numbers: a likely duration and a range. Our project timeline estimator turns phases and team size into weeks if you want a sanity check before talking to a builder. If the estimate is over budget, cut again from the "now" column, starting with anything that makes the core job nicer rather than possible.
Then write three things on one page:
- The scope. The problem sentence, the one job, the workflow steps and the screens.
- The out list. Everything in "later" and "never", so nobody is surprised.
- The success target. A behaviour, a number and a date: "ten paying firms within eight weeks of launch, seven of them still active at week twelve."
Show the page to two or three of the customers you interviewed. You are not asking for approval of each feature. You are asking one question: if this existed next quarter, would you pay for it at this price? A hesitant answer on day five costs a week. The same answer after launch costs the whole build.
What usually goes wrong in a scoping week?
Scoping for the investor deck, not the customer. The deck needs a vision; the MVP needs one job. Keep both, on separate pages.
Treating "later" as "never". Founders resist cutting because they fear the feature will be lost. The written "later" list with reasons fixes that.
Skipping the data model. Screens are easy to agree on. Data decisions hide the scope, and they surface in week six of the build if you skip them now.
Leaving billing for the end. Payment touches sign-up, access and the data model. How to add subscriptions with Stripe shows why it belongs in the first sprint.
The output of the week is also the brief you send to builders for quotes. Our guide to writing an app brief covers how to present it, and how much a web app costs shows what each extra role and integration adds, so you can see what the cuts saved.
Was this guide useful?