A scoping method, from three builds
MVP development: what to build, what to cut, and what it costs
MVP development is building the smallest version of a product that can prove someone will pay for it. The scoping rule that matters: version one contains the single thing you validated plus whatever is required to charge money for it, and nothing else. Most failed MVPs are not too small, they are too broad, and the cost is not the build, it is the six months spent building the wrong four features.
- ◆Realistic timeline for a focused MVP today: two to six weeks, not six months
- ◆The test of scope: can you describe version one in one sentence with no 'and'
- ◆Must be real on day one: the core action, payment, and a way to talk to users
- ◆Can wait: settings, roles, dashboards, an admin panel, a second use case
Almost every founder I speak to has a version one scoped at three times what it should be. Not because they are careless, but because every feature they add feels like it reduces risk. It does the opposite: each one delays the day you find out whether anyone wants this.
This is the scoping method I use, from building three companies and from reviewing a lot of other people's MVPs after they went wrong.
The workbook version of this guide
This page explains the thinking. The Launch Workbook makes you do it: seven modules with fields you fill in, saved as you go.
1. Write the one sentence, then defend it
Version one does one job for one type of person. Write it as a single sentence with no 'and' in it. If you cannot, you have two products and you should pick the one with the buyer you understand best.
Everything else goes on a kill list, written down and visible. A kill list is not a backlog. A backlog is a promise to build things later; a kill list is a record of what you decided not to build and why, which stops you relitigating it every week.
2. Build what has to be real, fake the rest
Three things must genuinely work on day one: the core action your user came for, taking payment, and a channel where you can talk to the people using it. Everything else can be you, behind the curtain, doing it manually.
Manual delivery is not a shortcut, it is the fastest research you will ever do. You learn the edge cases in week one instead of discovering them in a support queue in month six.
- ·Real: the core action, authentication if it gates value, payment, and basic tracking
- ·Manual for now: onboarding, reporting, anything that runs once a week, anything with under ten users
- ·Not yet: settings pages, permission roles, integrations nobody has asked for by name, a mobile app
3. Choose a stack you will not have to leave
Pick boring, well documented infrastructure with managed auth, a managed database and a hosting layer that scales without you. The correct stack for an MVP is the one your team, or the AI tools you are briefing, can move fastest in while leaving the data model clean.
The expensive mistake is not the framework. It is the data model. Get your core entities and their relationships right on paper before anything is built, because that is the thing you cannot cheaply change later.
4. What MVP development actually costs
Cost tracks scope, so the honest answer is that it depends on how disciplined the previous three steps were. A focused MVP built by a founder using modern tooling costs a domain, hosting and model usage. The same product scoped as a wishlist and handed to an agency runs into five or six figures and takes months.
Before you get a quote, do the scoping. A development shop is quoting your feature list, and your feature list is the thing that is wrong.
5. Ship, then read the only two signals that matter
After launch, ignore everything except whether people complete the core action, and whether they pay. Traffic, signups and enthusiasm in calls are all noise at this stage.
If people complete the action but will not pay, you have a pricing or buyer problem. If they pay but do not come back, you have a product problem. Those two failures need completely different responses, and conflating them is how founders spend a year fixing the wrong thing.
In version one, or on the kill list
| Feature | Verdict | Why |
|---|---|---|
| The core action | Build it | It is the product |
| Payment | Build it | Free users do not prove a business |
| Signup and login | Only if it gates value | Otherwise it is a barrier before the value |
| Onboarding flow | Do it manually | Ten users can be onboarded by you, on a call |
| Settings and preferences | Kill list | Nobody churns from an MVP over settings |
| Admin dashboard | Kill list | Query the database directly |
| Integrations | Only if a paying customer named one | Otherwise it is speculation |
| Mobile app | Kill list | A responsive web page answers the question |
Common questions
What is MVP development?
Building the smallest version of a product that can prove people will pay for it, scoped to a single job for a single type of user, with payment working from day one.
How long should MVP development take?
Two to six weeks for a properly scoped product using modern tooling. If your estimate is six months, the problem is almost always scope rather than engineering speed.
How much does it cost to build an MVP?
A founder building a focused MVP themselves pays for a domain, hosting and model usage. Agency quotes run into five or six figures, and the number is driven almost entirely by how long your feature list is. Cut the list before you ask for a quote.
What should be included in an MVP?
The core action, a way to take payment, and a channel to talk to users. Onboarding, reporting and anything used by fewer than ten people can be done manually by you until it hurts.
Should I build an MVP or validate first?
Validate first. Twenty conversations and a page that asks for a real commitment costs you a week. Building first costs you a quarter and answers the same question less clearly.
You can read this, or you can do it with someone who has done it three times.
Zero to Entrepreneur is an eight week live cohort with 12 seats. You finish with a product live, real customers, and the numbers to decide what happens next.