The range, and why it's wide
The range is wide because "MVP" describes a philosophy, not a fixed scope — the same idea can be validated with a five-screen app or over-built into something that looks like a full product before a single customer has confirmed they want it. The cost difference between those two is the entire budget conversation.
What actually drives the number
- Number of core workflows. Every additional "core" thing a user can do roughly multiplies scope — not adds to it, multiplies, because each workflow needs its own edge cases, error states, and testing.
- Whether it needs to handle money. Payments, subscriptions, or payouts bring in compliance, edge cases (failed payments, refunds, disputes), and testing rigor that a feature-only MVP doesn't need.
- Two-sided vs. one-sided. A marketplace or platform needs both sides of the workflow built and tested — supply and demand — roughly doubling the surface area versus a single-user-type product.
- Admin and internal tooling. Founders often forget to budget for the internal dashboard that lets *them* see what's happening — support tooling, basic analytics, content moderation — until they're three weeks post-launch with no way to answer a support ticket.
- Platform count. Web-only is the cheapest starting point. Native iOS and Android alongside web roughly triples the surface you're maintaining, even with cross-platform frameworks reducing some of that.
The trap that blows most MVP budgets
It's rarely a single bad decision — it's a series of individually reasonable ones. "While we're building the signup flow, let's also add social login." "While we're building the dashboard, let's add a settings page nobody asked for yet." Each addition sounds small in isolation and the sum quietly becomes a different, larger project than the one that was scoped and quoted.
Before adding anything to MVP scope, ask: "will real users tell us something we don't already know if this ships without it?" If the honest answer is no, it's not an MVP feature — it's a v2 feature wearing an MVP costume, and it belongs on the list for after you have actual users to learn from.
Fixed price vs. time & materials, for an MVP specifically
| Fixed price | Time & materials | |
|---|---|---|
| Best when | Scope is genuinely locked and well-understood upfront | You expect scope to evolve as you learn — which is most real MVPs |
| Risk | Any scope change becomes a change order — friction exactly when you're learning fastest | Requires trust in the team's estimates and honest reporting |
| Fit for an MVP | Works for a narrow, well-defined slice | Usually the better fit — MVPs exist to learn, and locking scope fights that purpose |
Most experienced teams will tell you the same thing: for a genuine MVP — where the entire point is discovering what you don't yet know — time & materials with a firm budget cap and weekly visibility into what's shipping tends to serve founders better than a fixed-price contract that penalizes exactly the kind of scope adjustment an MVP is supposed to enable.
A realistic example scope
| Included | Deliberately excluded (v2 list) |
|---|---|
| Auth, one core user workflow end-to-end, basic admin view, payments (if revenue-generating from day one) | Social login, advanced analytics dashboards, native mobile apps, internal tooling beyond the bare minimum, anything "nice to have" that doesn't test the core hypothesis |
Want a real number for your idea?
Tell us the core workflow and we'll give you an honest scope and estimate — including telling you what to cut.
Frequently asked questions
Should we build the MVP ourselves to save money?
If someone on the founding team can genuinely ship it fast, yes — speed to a real user test is the whole point. The trade-off is opportunity cost: time spent building is time not spent talking to customers, which is usually the scarcer resource pre-revenue.
How long does a typical MVP take?
A narrow, single-workflow MVP is commonly 6–10 weeks. Adding payments, a second user type, or native mobile extends that — as a rule of thumb, each major addition from the cost-driver list above adds real weeks, not days.
What happens after the MVP validates the idea?
Ideally, a lot of the v2 list gets reprioritized based on what real users actually asked for — which is usually different from what the founding team guessed pre-launch. This is the actual return on keeping the MVP narrow in the first place.
Is a no-code MVP a legitimate option?
For validating demand before writing any code — a landing page, a manual/concierge version of the service — absolutely, and often the right first step. It tends to hit real limits once the core workflow needs custom logic or has to scale past a handful of users.