Most first versions are too big. Not because founders are careless, but because every feature on the list sounds reasonable on its own, and nobody wants to launch something that looks unfinished. The result is a version one that takes nine months instead of three, uses up most of the budget, and still teaches you less than a smaller release would have. Getting MVP scope right is mostly about deciding, with a clear rule, what can wait.
Here is a practical method for cutting a wish list down to a first release, followed by a worked example.
What an MVP is actually for
A minimum viable product is the smallest version of your product that real users can use for real, and that tells you whether the idea works. The important words are "real users" and "tells you". A prototype that only your team clicks through is not an MVP. Neither is a version with everything you can imagine.
So before listing features, write one sentence: "Version one exists to find out whether [specific users] will [specific behavior]." For example: "…whether busy parents in one city will book and pay for home cleaning through an app instead of phoning someone." Every scoping decision below comes back to that sentence.
A five-step method for setting MVP scope
1. Map the core path, end to end
Write down the one sequence of steps a user must complete for your sentence to be tested: find, sign up, do the main thing, pay, get the result. For the cleaning app that is: choose a service, pick a time slot, enter an address, pay, get a confirmation, have the cleaner arrive, leave a rating. Anything on this path is a candidate for version one. Anything off it has to argue its way in.
2. List everything else, honestly
Now write down every other feature anyone has suggested. Do not filter yet. It is easier to cut from a visible list than to argue about features that live in people's heads.
3. Apply the launch-day test
For each feature, ask: if this is missing on launch day, what actually happens? There are three possible answers:
- Users cannot complete the core path, or you cannot run the business. It is in.
- Users are mildly inconvenienced, or your team has to do something by hand. It waits.
- Nothing anyone would notice. It waits, and probably moves to "maybe never".
4. Replace features with manual work
Many features exist to save your team time. At launch volumes, your team has time. An admin can assign jobs from a simple dashboard instead of an automatic matching algorithm. Invoices can go out from your accounting software. Customer support can be a WhatsApp number. Automate these once the manual version becomes painful, which is also the point at which you understand the process well enough to automate it properly.
5. Set a time box and cut to fit
Decide how long version one may take (for many products, 8–16 weeks is a sensible first target) and let the estimate decide what fits. If the must-haves do not fit, the better fix is usually to narrow the audience, such as one city, one customer type or one platform, rather than rush the build.
If you publish on Android from a new personal Google Play developer account, add time for the closed test Google requires before production access: at least 12 testers opted in for at least 14 days. It belongs inside the time box, not after it.
The method applied to a home-cleaning app
Imagine a founder in one city with a wish list of 21 features for a home-cleaning service. Here is how the five steps sort it.
Version one, eight features:
- Phone number sign-up and login
- Choose service type and home size, and see a fixed price
- Pick an available time slot
- Enter and save an address
- Card payment at booking
- Confirmation and reminder notifications
- A simple web dashboard where an admin assigns a cleaner and marks jobs done
- A rating after each visit, with an optional comment
Replaced by manual work for now: automatic cleaner matching (the admin assigns), cleaner payouts (a weekly bank transfer from the accounting system), rescheduling (the customer messages support), and late cancellations (handled by support under a written policy).
Later, once the numbers justify it: a separate app for cleaners, weekly subscriptions, referral credits, in-app chat, more cities, promo codes, a loyalty scheme, tipping and live cleaner tracking.
Two decisions here are worth noticing. First, the cleaner app, which felt essential, is not needed at launch: cleaners can receive their jobs by SMS or a shared calendar. Dropping it removes a large share of the work, because a second app means a second set of screens, permissions, testing and store submissions. Second, the rating stayed in even though nobody needs it to complete a booking. It is the cheapest way to learn whether the service is any good, and that is what the founder's sentence is really asking.
What not to cut
"Minimum" applies to features, not to quality. Some things stay in version one even though users never see them:
- Security basics. Proper authentication, encrypted connections, sensible permissions, and customer data stored only where it should be. Fixing security after a leak costs far more than doing it now.
- Correct money handling. Payments, amounts and receipts must be right from the first transaction.
- Analytics on the core path. If you cannot see where users drop off, the MVP cannot answer its question.
- Backups and error reporting. There will be bugs. You need to hear about them before your customers tell you.
- Enough substance for the app stores. Apple's App Review Guidelines say, under 4.2 Minimum Functionality, that an app should offer more than a repackaged website and that apps without adequate utility may not be accepted. An MVP that just wraps your website in an app shell risks rejection. Guideline 2.1 also expects submissions to be final versions with placeholder content removed.
Web first or app first?
If your core path works well in a browser, a web MVP is usually cheaper and quicker to change: no store reviews, instant updates, one codebase. That suits most B2B tools, services tested in a small area, and anything people use at a desk. A custom web application is often the right first step, with apps added once the idea has proven itself.
Go app-first when the core value needs the phone itself: location, camera, push notifications, offline use, or a habit people return to several times a day. Even then, build once for both platforms. Building in Flutter for both stores keeps an MVP budget from being split across two separate apps. For what each feature tends to add to the bill, our guide to what a mobile app costs walks through an estimate line by line.
Signs your MVP scope is still too big
- You cannot explain version one in two sentences.
- It serves more than one type of paying user, and you have not yet tested either.
- Some features are there "because competitors have them".
- The estimate is longer than you can fund without revenue or new investment.
- Nobody can name the number that will tell you whether it worked.
If two or more of these are true, go back to step three and be stricter. Features you cut now are not lost. They are waiting for evidence.
What to do this week
Write your one-sentence purpose, map the core path, and run the launch-day test on every line of your wish list. Then write up what survives as a requirements document developers can quote from, with the manual workarounds noted, so vendors price the same, smaller product.
If you want someone outside the project to make the cut with you, share your feature list with us. We will tell you what we would build first, what we would leave out, and why.
