Quick answer. The MVP scope test is simple: for every feature you want to build, ask "would a real customer pay for this today without it?" If yes, cut it from version one. The goal of an MVP isn't to build a small version of your final product — it's to build the smallest thing that lets you find out whether anyone will pay for the core value at all. Most first-time founders' initial scope is two to three times bigger than it needs to be, and almost every wasted dollar in a first build comes from features nobody asked for yet.
Key takeaways
- The MVP scope test asks one question per feature: would a real customer refuse to pay or use the product at all without it? If not, cut it from version one.
- Most first-time founders' initial scope is two to three times bigger than it needs to be — almost every wasted dollar goes toward features nobody asked for yet.
- In the worked marketplace example below, running the test cut the build from ten feature areas to five, roughly halving both cost and time to a testable product.
- Matching a competitor's full feature set on day one means matching their cost structure without their revenue.
- Leave cut features out silently rather than asking early users about them — "would you want ratings and reviews?" almost always gets a polite yes regardless of real need.
Why Scope Is the Single Biggest Cost Driver
The single biggest cost driver in an MVP is what you build, not how you build it. Founders often assume the bigger lever is which tools, which developer, or which studio they use — but a tightly scoped MVP built by a competent team will always beat a bloated one, regardless of how efficient the build process is.
This is worth saying plainly: no amount of AI-assisted speed fixes a scope that's too big. If you cut your build cost with faster tooling but keep twice as many features as you need, you've just built the wrong-sized product faster. See Why AI-Assisted Development Makes MVPs Cheaper, and Where It Doesn't Help for why scope and tooling are separate levers.
The MVP Scope Test, Step by Step
- List every feature you currently imagine in version one. Be honest — include the "obviously necessary" ones too, not just the ambitious ones.
- For each feature, ask: would a real customer refuse to pay, or refuse to use the product at all, without this specific feature? Not "would it be worse without it" — worse is not the bar. The bar is whether the core value is undeliverable without it.
- Sort into three piles: must-have (the product doesn't work without it), strong-want (would clearly improve retention or conversion, but the product functions without it), and nice-to-have (you want it, but you couldn't explain why a customer would care yet).
- Build only the must-have pile for version one. Everything else waits until real users tell you it's actually needed.
- Re-run the test after every round of user feedback. Scope discipline isn't a one-time exercise — it's the operating mode for the whole MVP phase.
A Worked Example: A Marketplace App
Imagine a founder building a marketplace connecting Melbourne dog walkers with pet owners. Their first feature list, before applying the test:
- User accounts for both owners and walkers
- Search and filtering by suburb, price and availability
- In-app messaging
- In-app booking and calendar sync
- Ratings and reviews
- In-app payments with automatic payout splitting
- Walker verification (police check upload)
- Push notifications
- A referral program
- An admin dashboard for the founder
Run each through the test: would an owner refuse to book a walker without this?
| Feature | Must-have? | Reasoning |
|---|---|---|
| User accounts | Yes | Can't book or be found without one |
| Search and filtering | Yes | Core discovery mechanism |
| In-app booking | Yes | The core transaction |
| In-app payments | Yes | Trust and convenience are the product's whole value |
| Walker verification | Yes | Safety is non-negotiable for this category |
| Messaging | No | A phone number or email exchange works for version one |
| Ratings and reviews | No | Matters at scale, not with the first 20 bookings |
| Automatic payout splitting | No | Manual payouts are fine until volume makes it painful |
| Push notifications | No | Email works for early users |
| Referral program | No | Meaningless with no existing user base to refer from |
| Admin dashboard | No (minimal only) | A spreadsheet is an admin dashboard at this stage |
That cuts the build from ten feature areas to five — roughly halving both the cost and the time to a testable product, without touching the actual value proposition.
Where Founders Push Back — and Why the Pushback Is Usually Wrong
"But competitors have all of this." Competitors built those features after they had users to justify them, not before. Matching a competitor's full feature set on day one means matching their cost structure without their revenue.
"Users will judge it as incomplete." Early users judging an MVP as unpolished is expected and fine, provided the core value is genuinely there. Early users judging an MVP as useless because the core value is missing is the actual risk — and that only happens if you cut a must-have, not a nice-to-have.
"I only get one shot to make a first impression." You get one shot to make a first impression on a hundred people who don't know you exist yet. You get many shots to improve the product for the twenty who already tried it. Optimise for learning from the twenty.
"What if the strong-want features are what makes people pay?" This is the one legitimate pushback, and the answer is: you don't know yet, and that's exactly what version one with real users is for. If ratings and reviews turn out to matter enormously, you'll find out in week three of real usage — far cheaper than guessing it upfront and being wrong.
How This Connects to Cost and Timeline
Every feature you cut from must-have doesn't just save the cost of building it — it saves the cost of designing it, testing it, maintaining it, and it removes a place where bugs can hide. In our experience, halving a feature list rarely halves the cost exactly, because some foundational work (auth, hosting, the core data model — see What 'Engineered to Hold When Growth Arrives' Means in Practice) doesn't scale down linearly. But it consistently makes the difference between a build that fits a sensible first budget and one that doesn't. For typical Australian cost ranges by feature complexity, see How Much Does an MVP Cost in Australia in 2026?.
Running the Test on Your Own Idea
Before you brief a developer, a studio, or even an AI app builder, run your own feature list through the MVP scope test above. If you find yourself justifying a feature with "it would be nice" rather than "a customer can't get value without it," cut it — you can always add it back once real usage tells you it's needed. If you want a structured way to pressure-test the whole idea, not just the feature list, the Idea Reality Check does that in a few minutes.
FAQ
What if I genuinely can't tell whether a feature is must-have or nice-to-have?
Default to leaving it out. The cost of discovering you were wrong (a user asks for it, you add it in a week) is almost always lower than the cost of building something nobody needed. If you're still unsure after that, it's worth talking it through with someone outside your own head — a co-founder, an advisor, or a quick call with a studio that's scoped this kind of product before.
Is the scope test different for B2B versus consumer products?
The test itself doesn't change, but the must-have bar tends to be different. B2B buyers often need specific integrations or compliance features to use a product at all (making them genuinely must-have even though they feel like "extras"), while consumer products more often have inflated must-have lists built from assumption rather than a real blocking requirement. Talk to your actual target users before assuming either way.
How many features should a good MVP have?
There's no fixed number — it depends entirely on what your core value proposition requires to be deliverable at all. What's consistent across good MVPs is that every single feature present can be directly tied to "the customer cannot get the core value without this." If you can't make that link for a feature, it doesn't belong in version one, regardless of the total count.
Should I show the cut features to early users, or just leave them out silently?
Leave them out silently for the most part. Asking "would you want ratings and reviews?" almost always gets a polite yes regardless of real need — people are agreeable about hypotheticals. It's far more reliable to watch what users actually struggle with in the must-have version and let that tell you what to build next.
What's the risk of scoping too tightly?
The main risk is cutting something that's actually load-bearing for trust or safety rather than convenience — in the dog-walking example above, walker verification stayed in because safety isn't a "nice-to-have" for that category. Run the test honestly rather than aggressively: the question is always "can a real customer get the core value without this," not "what's the absolute minimum I can get away with."
Next step
Once your scope is tight, Sketchli's AI-powered app development gets the must-have version built fast without adding back the features you just cut. Not sure your idea is there yet? Start with the Idea Reality Check, or book a free 30-minute call and we'll help you scope it properly.
Want to bring your idea to life? Contact us or chat on WhatsApp.