Web development · 5 min read
MVP Scoping: What to Leave Out of Version One
Most MVPs fail because they are not minimal. Here is the three-question test we use to cut scope before a single line of code gets written.
Every founder we scope a build with arrives with a feature list that is really a wish list for the finished company, not a plan for the first version. That is the single biggest reason MVP timelines slip: the "minimum" gets negotiated away one "just in case" feature at a time.
We scope custom builds for a living, and the pattern repeats across industries. A founder asks for a booking system and ends up specifying multi-currency invoicing, a referral program, and three user roles before they have a single paying customer to serve. None of that is wrong to want eventually. It is wrong to build before you know anyone wants the product at all.
Why MVP scope creep happens
Scope creep on a v1 rarely comes from the build team. It comes from founders protecting themselves against an uncomfortable question: what if the core idea does not work? Adding features feels like progress and de-risking. In practice it just delays the one test that actually matters, whether real users will use the core loop without being asked to.
The fix is not willpower. It is a scoping process that forces every feature to justify itself against the thing you are actually trying to learn.
Three questions that decide what makes v1
1. Does this let a user complete the core job, start to finish?
If the feature sits outside the single path a user takes from "I have a problem" to "my problem is solved," it is not v1. A marketplace app needs listing, discovery, and payment in v1. It does not need saved searches, seller analytics, or a referral program, because none of those are required to complete one transaction.
2. Can you fake it manually before you build it?
Anything you can run by hand for the first 20-50 users should stay manual. Onboarding emails, customer support routing, even matching buyers to sellers, a spreadsheet and a founder willing to do the work will tell you more about what to automate than a guess ever will. We have shipped MVPs where the "backend" for the first month was a Google Sheet and a human checking it twice a day.
3. Does it block revenue or trust, or is it just polish?
Payment processing blocks revenue. A broken signup form blocks trust. A missing dark mode blocks neither. We sort every requested feature into one of three buckets: blocks the core loop, blocks money or trust, or can wait. Only the first two buckets make it into v1.
| Keep in v1 | Push to v2 (or later) |
|---|---|
| The single core user action (book, buy, submit, match) | Multiple user roles and permission tiers |
| One payment method that actually works | Multi-currency, subscriptions, or usage-based billing |
| Manual admin tools (even a spreadsheet) | A polished internal admin dashboard |
| Basic email notifications | In-app notification centers and push |
| One clear signup path | Social login, SSO, multi-factor auth |
| Mobile-responsive web | A native mobile app |
45%
of features in the average software product are never used by anyone
Source: Standish Group CHAOS research, presented by Jim Johnson at XP2002
That statistic is from 2002 and software teams still relearn it every year. The features that never get used are almost always the ones added for a hypothetical user rather than the one sitting in front of you asking for help.
What this looks like in a real scoping session
When we scope a custom app with a client, we run the feature list through the three-question test in one sitting, usually 60-90 minutes. Anything that survives all three questions goes in v1. Everything else goes on a v2 list that we keep, not delete, because a feature that is wrong for launch is often exactly right six months later once the core loop is proven.
This is also where build vs buy decisions get easier. If a feature did not survive the three-question test, you probably should not be building it at all yet, off the shelf or custom. Spend the engineering budget on the one thing only a custom build can do for your specific workflow, and use existing tools for everything else until you have earned the complexity.
Scoping your own v1
If you are heading into a build, write your full feature wish list first, then run each line through the three questions above. Be honest about the manual-first test in particular. Founders consistently underestimate how long they can run a process by hand before it actually breaks.
If you want a second pair of eyes on the list before you brief a dev team, that is exactly the conversation we have at the start of every custom web application project. Getting scope right before the first sprint is the cheapest fix you will ever make on the project.
- Write the full wish list, then cut ruthlessly against the three-question test
- Keep a v2 backlog instead of deleting ideas, most are right, just early
- Run anything you can fake manually by hand for the first cohort of users
- Scope with the people who will actually build it, not in isolation
Questions people also ask
How long should an MVP take to build?
Most well-scoped MVPs for a single core workflow take four to eight weeks. If your estimate is running past twelve weeks, it is almost always a scope problem, not a complexity problem.
Should I build an MVP myself or hire a developer?
If you can validate the idea with no code (landing page, manual process, a spreadsheet) do that first. Once you need a real working product to onboard paying users, bring in a developer who can push back on scope, not just build whatever is on the list.
What is the biggest MVP scoping mistake?
Building for a future scale you do not have yet. Multi-tenant architecture, role-based permissions, and admin dashboards are the three features we see over-built most often in a first version.
