Most MVPs don't fail because the code was bad. They fail because the team built the wrong thing, or too much of the right thing, before a single customer touched it. Scoping fixes that. Done well, it takes five working days, not five weeks, and it saves months of build time.
This is the five-day scoping process we use with founders before writing any production code. You can run it yourself with a notebook and a calendar, or with a development partner. Either way, you finish the week with a feature list, a clickable prototype, a cost range and a launch plan you can defend to investors.
Why five days?
Scoping expands to fill whatever time you give it. Give a team a month and it will design the admin panel, the referral program and the dark mode. Give it five days and it is forced to answer the only question that matters for an MVP: what is the smallest product that proves people will use and pay for this?
A fixed week also keeps founders and engineers in the same room (or call) while decisions are fresh. Every day ends with a written decision, so nothing gets relitigated the following week.
Day 1: Define the problem and the one user who has it
Start with people, not features. By the end of day one you should be able to fill in this sentence with no hand-waving:
"[Specific user] struggles with [specific problem] when [specific situation], and today they work around it by [current workaround]."
The workaround is the most important part. If users currently solve the problem with a spreadsheet, WhatsApp groups or a part-time assistant, you have found your real competitor, and your MVP only needs to beat that.
Day 1 checklist:
- Pick one primary user persona. Two-sided marketplaces pick one side to win first.
- Write down the current workaround and what it costs them in time or money.
- List the 3–5 assumptions that, if wrong, kill the business (e.g. "clinics will pay monthly", "drivers have reliable data connections").
- Review any user interviews you have. If you have none, book five calls for days 2–4.
Day 2: Map the core user journey
Draw the single path a user takes from "I have this problem" to "the problem is solved". Not every screen, just the steps. For a car wash booking app, that might be: open app → pick service → pick time slot → pay → get confirmation → wash happens → rate.
Now mark every step as one of:
- Must build: the product doesn't work without it.
- Fake it: a human, a form or a third-party tool handles it behind the scenes for now.
- Later: valuable, but it doesn't test one of your Day 1 assumptions.
"Fake it" is where most of the savings come from. Manual approval instead of an automated KYC pipeline, a Stripe payment link instead of a custom billing system, a Google Sheet admin panel instead of a dashboard: all of these are legitimate MVP decisions. You can see how we later automated these steps properly in builds like Verified, but the first version rarely needs that.
Day 3: Cut the feature list ruthlessly
Turn the journey into a feature list and prioritise it with MoSCoW (Must, Should, Could, Won't). The rule we enforce: "Must" features should fit into 6–10 weeks of build for a small team. If they don't, keep cutting.
Features founders almost always over-scope in an MVP:
- Role-based permissions. Start with "admin" and "user".
- Analytics dashboards. Use a product analytics tool and export to a spreadsheet.
- Native apps on both platforms. A responsive web app or a single cross-platform app (we compared the options in React Native in 2025) covers most early tests.
- AI features "because investors expect it". Add AI where it removes a real step for the user, not as decoration.
- Settings pages. Hard-code sensible defaults and change them when users ask.
Write the "Won't" list down and share it. It is as important as the "Must" list, because it is what stops scope creep in week four.
Day 4: Prototype and test with real users
Build a clickable prototype of the core journey in Figma or a similar tool. It doesn't need polish, only the screens on the "Must build" path. Then put it in front of three to five people from your target persona.
Don't ask "would you use this?" Everyone says yes. Instead:
- Give them a task ("book a wash for Saturday morning") and watch where they hesitate.
- Ask what they would do right now without your product.
- Ask what they would expect to pay, and whether they would pre-order or join a paid pilot.
Adjust the prototype the same day. It is far cheaper to move a button in Figma than in production code.
Day 5: Choose the stack, estimate and plan the launch
With a validated journey and a short feature list, technical decisions get much easier. Day 5 produces four documents:
- Technical approach. Platform (web, mobile or both), core stack, third-party services and hosting. For most web MVPs we default to a proven setup like Next.js with a managed database, because boring technology ships faster.
- Estimate. A range per feature, not a single number, with the assumptions written next to it.
- Milestone plan. Two-week sprints, each ending with something a user can click.
- Success metrics. What number, measured how, by when, tells you the MVP worked (e.g. "20 paying clinics within 60 days of launch").
Common scoping mistakes to avoid
- Scoping by copying competitors. Mature competitors have features you don't need yet. Copy their core loop, not their settings page.
- Skipping the "Won't" list. Without it, every stakeholder conversation adds a feature.
- Treating the estimate as a quote. An estimate made on Day 5 is a range. It narrows as design and build progress.
- Building for scale on day one. Design so you can scale, but don't pay for microservices before you have a hundred users.
- No owner for decisions. One person on the founding team must have the final say on scope.
What you should have at the end of the week
- A one-paragraph problem statement and primary persona
- A core user journey with every step marked build, fake or later
- A prioritised feature list including a written "Won't" list
- A tested clickable prototype
- A technical approach, cost range and sprint plan
- Clear success metrics for launch
That package is enough to start building with confidence, raise a pre-seed round, or compare development partners on equal terms.
Frequently asked questions
How long does it take to build an MVP after scoping?
Most well-scoped MVPs take 6–12 weeks to build. Products with payments, compliance requirements or hardware integrations take longer. If your estimate is over four months, the scope is probably too big for a first version.
Can I scope an MVP without a technical co-founder?
Yes. Days 1–4 are product work, not engineering. For Day 5, bring in a technical advisor or a development partner to review the stack and estimate.
Should my MVP include AI?
Only if AI removes a step the user would otherwise do by hand, or the product can't exist without it. Using existing model APIs keeps the cost low, and you can swap in custom models later.
If you want help running this process, our MVP development team runs a fixed-length discovery sprint that ends with exactly these deliverables. Tell us about your idea and we will tell you honestly whether it's ready to build.