The word 'minimum' in minimum viable product is doing a lot of work, and most founders ignore it. The MVPs that never launch share a pattern: they were scoped as the full product with a few features removed, instead of as the smallest thing that proves the idea.
Here is the scoping process we use with founders before we write a single line of code.
Start with the one workflow
Every product has one core loop that creates its value. For a marketplace it is list, discover, transact. For a scheduling tool it is set availability, book, confirm. Write that loop down in one sentence. Everything in the MVP must serve that sentence; anything that does not is version two.
Separate must-have from must-have-eventually
Take your feature wish list and sort each item into three buckets: the core loop cannot work without it; the core loop works without it but users will ask for it quickly; and it would be nice. Only the first bucket goes in the MVP. Founders routinely put 60% of their list in bucket one on the first pass and 20% on the honest second pass.
- User roles: start with the fewest you can. Admin and user is often enough.
- Payments: can you invoice manually for the first 20 customers? Often yes.
- Notifications: email first; push and SMS later.
- Settings and preferences: almost always version two.
- Reporting dashboards: a weekly export beats a dashboard nobody has asked for.
Design the data model before the screens
Screens change constantly; the data model is expensive to change later. Decide what the core entities are, how they relate and what must be unique or auditable. A well-designed database for an MVP looks almost identical to the one in the mature product; a badly designed one gets rebuilt at the worst possible time.
Plan the admin tooling
Nobody budgets for the admin panel and everybody needs it. Who creates accounts, fixes a bad record, refunds a customer or exports data for an investor? If the answer is 'the developer runs a database query', you will burn engineering hours on support. Plan a basic admin area from the start.
Choose boring technology
An MVP is not the place to try an unfamiliar framework. Use a stack your team knows, with a managed database and hosting, and a clean API so a mobile app or integrations can follow. We typically reach for React with Node.js or Laravel for the application and Flutter if a mobile app is in scope. See how we scope software builds.
Set a launch date and work backwards
Twelve weeks is a healthy MVP timeline: two for discovery and design, eight for build, two for testing and launch preparation. If the scope does not fit, cut scope rather than extend time. The point of an MVP is to learn from real users, and every month of delay is a month without that learning.
A worked example
A founder came to us wanting a marketplace for specialist contractors with profiles, search, messaging, quotes, payments, reviews, dispute resolution and a mobile app. The core loop was: a customer posts a job, matched contractors respond, the customer picks one. The MVP shipped with job posting, a manually curated contractor list, email-based responses and a phone call to close. No payments, no app, no messaging. It validated demand in six weeks for a fraction of the original budget, and the second version added exactly what the first fifty customers asked for, which was not what the original list predicted.
What to measure after launch
An MVP exists to answer questions, so decide the questions first. Typical ones: do people complete the core loop? Where do they drop off? Do they come back? Would they pay, and how much? Instrument the product with basic analytics and event tracking from day one, talk to every early user, and keep a written log of what you learn. The next version is scoped from that log, not from the original wish list.
Common scoping mistakes
- Building for every user type instead of the one who feels the problem most.
- Adding a native mobile app when a responsive web app would prove the idea.
- Treating design polish as optional, then losing users to a confusing first screen.
- Integrating with every tool prospects mentioned instead of the one they all use.
- Skipping analytics, then having no idea why users left.
Each is a form of the same error: optimising for the imagined full product instead of for the next thing you need to learn.
Frequently asked questions
How much does an MVP cost?
For a web application with a focused scope, typically $20,000–$60,000. Mobile apps and complex integrations push that higher. Scope discipline is the biggest cost control available to you.
Should an MVP be built to throw away?
No. Build it properly on a sensible foundation, but build less of it. Throwaway MVPs are a myth; successful ones become the product.
What if investors want to see more features?
Investors want to see traction. A tight product with real users beats a feature-rich demo with none.
Founder & CEO of Devontix Solutions. Absaar leads strategy, automation planning and product thinking across every build, from the first discovery call to the running system. More about Absaar