Most MVPs are not minimum and do not validate much. They start as a lean idea, then pick up a referral program, a dark mode, a chat feature and an admin dashboard, until the first release takes nine months and tests everything at once. When results come in, nobody can tell which part worked.
A better approach is to name the one assumption that would kill the product if it were wrong, and build only what is needed to test it with real users. This guide shows how to find that assumption, how to use MoSCoW prioritization without letting everything become a must-have, and how we would cut a hypothetical marketplace app down to a first release.
What an MVP is for
An MVP exists to answer a question cheaply. The question is usually some form of "will enough of the right people do the thing we need them to do?" Everything in the first release should either help answer that question or be required for the app to function at all, such as sign-in or store compliance.
That framing changes how you judge features. A polished onboarding carousel is nice, but if your risk is whether suppliers will list inventory, the carousel does not reduce that risk. A simple supplier listing flow does. Teams building custom apps for a specific workflow often find the riskiest assumption sits with the less glamorous user group.
Find your riskiest assumption
- 1
List assumptions
Write every belief the business depends on: people have this problem, they will pay, they will switch from what they use now, the other side of the market will show up, the unit economics work.
- 2
Score each one
Rate two things from 1 to 5: how fatal it is if wrong, and how little evidence you have today.
- 3
Pick the top one or two
Multiply the scores. The highest product is what the MVP must test first.
- 4
Write the test
State what users will do, how many, and over what period, for example "40 sellers list at least one item within four weeks of invitation."
Using MoSCoW without fooling yourself
MoSCoW sorts features into Must have, Should have, Could have and Won't have (this time). It is simple and stakeholders understand it. Its weakness is that everyone argues their feature into the Must column.
| Category | Definition we use for an MVP | Typical share of effort |
|---|---|---|
| Must have | Without it the riskiest assumption cannot be tested, or the app cannot ship to the stores | Most of the build, but leave room for contingency |
| Should have | Improves the test meaningfully but a manual workaround exists | Planned, first to drop if time runs short |
| Could have | Pleasant, does not affect the result of the test | Only if ahead of schedule |
| Won't have (this time) | Valid ideas parked for after the results are in | Zero, but written down so they are not lost |
Two rules help. First, every Must needs a one-line reason linked to the assumption. Second, reserve contingency: if Must items already fill the whole budget, you have not prioritized; you have listed. Our article on what drives app development costs explains why integration and edge-case work often take longer than the screens themselves.
Worked example: a hypothetical equipment-rental marketplace
To make this concrete, here is an invented example, not a client project. Imagine a marketplace where homeowners rent tools from neighbors. The founder's full vision includes listings, search, booking, payments with deposits, ratings, in-app chat, insurance, delivery scheduling and a referral program.
The riskiest assumption is supply: will enough people in one neighborhood list tools they own? Demand for cheap tool rental seems plausible; supply is unproven. So the MVP focuses on making listing easy and letting a small group of renters book.
| Feature | MoSCoW | Reasoning |
|---|---|---|
| Photo-first listing in under two minutes | Must | Directly tests the supply assumption |
| Phone number sign-in | Must | Needed for trust and contact; simplest auth |
| Browse by category within one area | Must | Renters need to find items; full search can wait |
| Booking request and accept/decline | Must | Shows whether listings convert into rentals |
| In-app payment with deposit hold | Should | Payment on pickup works for a pilot area; adds compliance work |
| Ratings and reviews | Should | Useful for trust, but early users can be vetted manually |
| In-app chat | Could | SMS or phone calls cover a small pilot |
| Delivery scheduling | Won't | Separate logistics problem; test after supply is proven |
| Referral program | Won't | Growth lever, not a validation tool |
Notice how much manual work replaces software here: the founder vets users personally, payments happen at pickup, and messages go by text. That is fine for 200 users in one area. It would not be fine at 20,000, which is exactly why you test first.
Technical choices that keep an MVP cheap to change
- One codebase where it fits. A cross-platform framework lets you reach iOS and Android users with one build while you learn.
- Managed backend services for auth, storage and notifications, so the team writes product code instead of infrastructure.
- Analytics from day one, tied to the success metric, with events named before development starts.
- Feature flags so you can switch experiments on and off without a store release.
- Clean boundaries around shortcuts, so replacing manual steps later does not mean rewriting screens.
Set the success metric and review date up front
Before a line of code is written, agree three things with your stakeholders: the metric, the threshold, and the date you will look at it. For the example above, that might be "at least 40 active listings and 15 completed rentals in the pilot area within six weeks of launch."
Agreeing in advance stops two common failures: declaring success on vanity numbers like downloads, and endlessly extending the test because the result is uncomfortable. If you plan to keep building after the review, discuss whether a time and materials or dedicated team model suits the next phase better than a fixed scope.
Frequently asked questions
How long should a mobile MVP take to build?
It depends on scope and integrations, but if your estimate runs well beyond a few months, revisit the Must list. Long MVPs usually mean the scope is testing several assumptions at once.
Should an MVP be native or cross-platform?
Cross-platform is often the faster way to test with both iOS and Android users. Native makes sense when the riskiest assumption depends on platform features, such as advanced camera, Bluetooth or background processing.
Is an MVP the same as a prototype?
No. A prototype shows how something might work, often without real data. An MVP is a working product used by real people, so it needs sign-in, real data and store-ready quality, just with a narrow scope.
What happens to the Won't-have list?
Keep it. After the review date, re-score those items against what you learned. Many will drop away entirely; a few will become the next release.
This article is general guidance based on common delivery practice. It is not legal, tax or financial advice; platform rules and regulations change, so confirm current requirements with the relevant provider or adviser.