Quick answer
Scope an MVP around the one riskiest assumption: one user, one main journey, must-have features only (sorted with MoSCoW), off-the-shelf services for everything else, a time box of roughly 8 to 16 weeks and success metrics agreed before launch.
- If a feature does not help test the key assumption, leave it out of version one.
- Buy login, payments, email and notifications instead of building them.
- Pick a mainstream stack with a large talent pool so the MVP can grow into the product.
- Keep part of the budget for improvements after launch.
Most failed MVPs don’t fail because of bad code. They fail because they took too long, cost too much and tried to do too many things before a single real customer used them. A Minimum Viable Product exists to answer one question as cheaply and quickly as possible: will people use and pay for this?
Here is the scoping process we walk founders through before a single line of code is written.
Step 1: Write down the one assumption that matters most
Every product idea rests on a few assumptions. Find the riskiest one and build the MVP to test it. For example:
- “Clinic owners will pay monthly for online booking.”
- “Shoppers will buy jewellery in bulk if the price per piece drops.”
- “Field teams will log jobs from a smartwatch instead of paper.”
If a feature doesn’t help test that assumption, it probably doesn’t belong in version one.
Step 2: Define one user and one main journey
Pick the single most important type of user and map the one journey that delivers value to them, from sign-up to the moment they get what they came for. That journey is your MVP. Secondary users, such as admins, can often start with simple internal tools or even a spreadsheet.
Step 3: Sort features with MoSCoW
| Category | Meaning | Example for a booking app |
|---|---|---|
| Must have | Without it, the core journey doesn’t work | See available slots, book, get confirmation |
| Should have | Important, but there is a manual workaround | Reminders (send them manually at first) |
| Could have | Nice to have | Reviews, loyalty points |
| Won’t have (yet) | Explicitly out of scope for version one | Multi-location chains, marketplace features |
Be ruthless. A good MVP feels slightly embarrassing to the founder and perfectly useful to the first customers.
Step 4: Buy, don’t build, everything that isn’t your product
Login, payments, email, notifications, analytics, maps and chat all have reliable services you can plug in. Building them yourself adds weeks and creates code you have to maintain. Spend your budget on the part that makes your product different.
Step 5: Choose a stack you can grow on
You don’t need to design for millions of users on day one, but you shouldn’t paint yourself into a corner either. Choose mainstream technology with a large talent pool, such as a cross-platform mobile framework and a proven back end like Laravel, Django, Ruby on Rails or Node.js, so the MVP can grow into the real product instead of being thrown away. Our comparison of Django, Laravel and Node.js can help.
Step 6: Set a time box and success metrics
- Time box: most MVPs should launch in roughly 8 to 16 weeks. If the scope doesn’t fit, cut scope, not quality.
- Success metrics: decide before launch what result means “continue”, “change direction” or “stop”. For example: a number of paying customers, a weekly active usage target or a conversion rate.
Step 7: Plan what happens after launch
Launch is the start of learning, not the finish line. Reserve part of your budget for the first rounds of improvements based on real usage. Talk to every early customer you can. Their behaviour will tell you what to build next far better than any feature list.
Common MVP scoping mistakes
- Building for every type of user at once
- Perfecting design before validating demand
- Custom-building commodity features such as login and payments
- No success metric, so nobody knows whether the MVP worked
- Spending the whole budget on version one, leaving nothing to iterate
Frequently asked questions
How much should an MVP cost?
It depends on scope and team rates, but a well-scoped MVP is usually a few hundred hours of work, not thousands. Estimate the hours for your must-have features and multiply by the team’s rate. Our guide to app development cost has worked examples.
Should my MVP be a mobile app or a web app?
Start where your users already are and where it is cheapest to test. A responsive web app is often fastest. Choose mobile first if the core value needs a phone, such as location, camera, notifications or offline use.
Can a no-code tool be my MVP?
Sometimes, yes. No-code tools are great for testing demand quickly. Move to custom development once you have proven the idea and need performance, custom logic or scale.
Get help scoping your MVP
We run short discovery workshops that turn an idea into a scoped, estimated MVP plan: features, user journeys, tech stack and timeline. Book a free consultation or see our software product engineering services.