Founders usually over-scope their first build. It's the single most common and expensive mistake we see. The fix is two paragraphs long, but almost nobody follows it.
The framing that actually helps
"MVP" has been diluted to mean "whatever we can afford." That's not useful. The useful framing is this: an MVP exists to validate one specific hypothesis. A full product exists to serve a known, validated market.
If you don't know your hypothesis, you can't scope an MVP. If you're not sure about the market, you shouldn't be building a full product yet.
The four questions
1. Do you have a paying customer lined up?
If yes, skip the MVP. You're not validating — you're delivering. Scope the full thing they need, get a deposit, ship.
If no, you're validating. Build an MVP. Anything more is premature.
2. How much of your monthly burn does this build consume?
If the build costs more than 3 months of your runway, it's too expensive regardless of which path. Scope down. Ship something small, charge for it, extend runway, iterate.
A founder with $60K in savings building a $50K MVP is a founder going out of business. A founder with $60K in savings building a $15K MVP has a real shot.
3. What's the ONE thing your product needs to do better than the alternatives?
Write it down in a sentence. Then scope to ship ONLY that thing.
If you can't write the sentence, you're not ready to build. Go do 20 customer interviews first.
4. What's the earliest evidence you could get that users care?
For a SaaS tool: 10 users using it weekly.
For a marketplace: 3 transactions.
For an internal tool: the team adopting it without being forced.
Scope the MVP to produce that evidence. Nothing more.
Typical MVP scope (what $25K–$40K actually buys)
- One primary user flow, polished end-to-end
- Authentication (email/password, maybe Google SSO)
- One or two core features that validate the hypothesis
- Basic admin tooling (enough to see what's happening)
- Payment integration if revenue is part of the hypothesis
- Deployed to staging + production, basic monitoring
That's it. No marketing site built in (use a template). No mobile app (unless that's the point). No multi-role permissions. No notifications. No multi-language. No analytics beyond basic tracking.
Typical full-product scope (what $75K–$150K buys)
- Multiple user flows, designed for different personas
- Proper role-based access control
- Payments, billing, subscriptions, taxes
- Admin dashboard for ops team
- Integrations with 2–3 external tools
- Real QA, security review, performance testing
- Marketing site, onboarding flow, help docs
- Mobile app if that's in scope
The most expensive mistake
Building a full product when you needed an MVP. The founder raises a seed round, feels pressure to show progress, commissions a full $120K build, ships 8 months later — and discovers the hypothesis was wrong. Now there's no runway to pivot.
The opposite mistake (building an MVP when you needed a full product) is cheaper to fix. You just extend and add what's missing. Going backward from full product to MVP isn't possible.
A simple rule we follow in scoping calls
If you're uncertain which to pick, build the MVP. Worst case, you have to extend and spend more. Best case, you learn something that saves you a fortune. WebCentriq scoping playbook, updated for 2026
What AI-accelerated delivery changes
In 2025, an MVP took 8–12 weeks. In 2026, with proper AI tooling on the agency side (not vibe-coding slop — real senior engineers using AI for the boilerplate layer), a good MVP ships in 4–6 weeks. That means you can test two hypotheses in the time you used to test one. The best founders we work with now A/B test hypotheses before scaling spend.
But this only works if the shop using AI is senior-led and has real human code review. The cheap vibe-coded option still loses money, just faster. See our piece on AI-accelerated vs traditional development for the fuller breakdown.
Not sure which path you need?
Describe what you have in mind. Our AI estimator suggests the right scope and timeline. Senior engineer reviews before you get the plan.