"MVP" has become the most abused word in software. Founders show me a 40-feature spec and call it an MVP. Developers quote six figures and call it founder-friendly. Here is what an MVP actually is and what it should actually cost.
What MVP means (the part everyone skips)
Minimum VIABLE product. Viable means one core job gets done for real users. Not a demo. Not everything your product will someday do. If your app's promise is "book a vet appointment in 60 seconds," the MVP is exactly that, with one payment method, one city, one user type.
Everything else is phase two, funded by proof from phase one.
Budgets by stage
| Stage | Goal | Realistic budget |
|---|---|---|
| Validation | Prove people want it | $500 to $2,000 (landing page + waitlist, no code) |
| MVP | Prove people use it and pay | $5,000 to $15,000 (solo dev / small studio) |
| Polished v1 | Prove a business | $20,000 to $50,000 (agency or senior team) |
The jump from validation to MVP is where most founders should spend, and where most instead skip straight to the third row with borrowed money.
The five classic budget killers
- Three user types at launch. "It's for pet owners, vets, AND shelters." Pick one. The others are version 2 and 3.
- Both platforms at once. An iOS + Android + web launch triples testing and design. One platform first is not a compromise, it is a decision.
- Custom design systems. Your MVP does not need a bespoke design language. It needs clean, standard screens that feel trustworthy.
- "Small" social features. Profiles, follows, feeds, chat. Each one is a real feature with real moderation headaches. None belong in an MVP unless they ARE the product.
- Pre-optimizing for scale. "What if 100,000 users come?" Then you will happily pay to rearchitect, because that is a good problem funded by revenue.
What a $10,000 MVP looks like in practice
A real example from my clients, numbers rounded:
- One platform (iOS), one user type (customers)
- Accounts, browsing, booking, Stripe payment, push reminders
- Standard UI patterns, custom branding on top
- 4 weeks of work, fixed price
It launched, took real bookings, and the second version was designed from actual usage data instead of guesses. That is the whole point: the MVP buys you information cheaper than any other method.
Where to spend and where to cut
Never cut: payments (bugs here cost trust and money), basic security, onboarding (the first 60 seconds), analytics so you can see what users do.
Always cut at MVP stage: admin dashboards (use off-the-shelf database tools), 10 languages, dark mode, tablet layouts, "settings" screens full of toggles nobody needs yet.
The number that matters more than the build cost
Set aside 20 to 30% of your budget for what happens after launch. Real users will show you things nobody predicted: one flow everyone abandons, one feature nobody touches. Cheap pivots after launch are what turn an MVP into a business. Founders who spend 100% on the build and 0% on learning end up with a beautiful, wrong product.
How to get an MVP built without the horror stories
Write one sentence: "This app helps [who] do [one job] without [pain]." Send it to three developers. The one who replies with questions about users and scope, a fixed price, and a launch date is your developer. The one who replies "great idea, that will be $60,000" is your exit cue.
If you want to pressure-test your MVP scope, send me your one sentence. I will tell you what I would cut, what it would cost, and how long it would take, with numbers.