Ask five agencies to quote the same MVP and you’ll get five numbers spanning an order of magnitude. That’s not dishonesty. It’s that “MVP” describes an intent, not a scope, and each firm has silently filled the gaps with different assumptions.
The useful question isn’t “what does an MVP cost.” It’s “which decisions in my brief are driving the number, and which of them am I actually attached to.”
The four decisions that drive most of the cost
1. How many user types the system has
This is the most underestimated cost multiplier in software. A product with one kind of user is dramatically cheaper than one with three, because every additional role brings its own permissions, its own screens, its own edge cases, and its own testing surface.
A marketplace with buyers, sellers, and admins isn’t three times a single-user app — it’s closer to four, once the interactions between roles are handled.
The lever: launch with one role and administer the rest manually. Plenty of successful products ran their first months with the “admin panel” being a founder editing the database.
2. Whether you’re integrating with anything
A self-contained product is predictable. The moment it must talk to a payment processor, an accounting system, a CRM, a shipping provider, or a legacy internal system, cost and risk both rise — and integrations are where estimates most often break, because the other system’s behaviour isn’t yours to control.
Integrations against mature, well-documented APIs (Stripe, for instance) are relatively contained. Integrations against an undocumented internal system, an old SOAP endpoint, or a partner’s staging environment that’s down half the time are open-ended, and honest vendors price them as time and materials for that reason.
The lever: for v1, replace an integration with a CSV export and a manual step. It’s unglamorous and it defers real cost until you know the product works.
3. Whether you need real-time behaviour
Request-response applications are well-understood. Live collaboration, presence indicators, instant notifications, real-time dashboards — these require different infrastructure, more complex state handling, and considerably more testing.
The lever: ask whether “live” is a requirement or a preference. A 30-second refresh satisfies most operational use cases and costs a fraction of true real-time.
4. What regulatory regime applies
Handling health records, payment data, or personal data at scale changes the engineering work — audit logging, access controls, retention rules, encryption, data residency, and the documentation to evidence all of it. This isn’t overhead to be trimmed; it’s a category of work that must exist before launch.
The lever: none, really. But scope it explicitly rather than discovering it at penetration-test time. And prefer designs that keep regulated data in as few places as possible.
What barely moves the number
Founders frequently negotiate hardest on the things that matter least:
- Which framework is used. Cost differences between mainstream stacks are marginal compared with scope. Let the team use what they know well.
- Visual polish of a design. Design costs are real but rarely dominant. Cutting design to save money usually costs more in rework once users are confused.
- Hosting. Cloud spend for an MVP is small. Architecting around it prematurely is a classic waste.
What an MVP should and shouldn’t contain
An MVP exists to answer a question. Everything not serving that question is deferrable.
In: the single core workflow, end to end. Whatever authentication that workflow requires. Enough instrumentation to learn what users do. A way to charge, if the question is whether people will pay.
Out, almost always: an admin dashboard (use the database), multi-language support, granular role permissions, an onboarding tour, a mobile app and a web app, dark mode, a settings page nobody has asked for, and anything justified with “we’ll need it later.”
The discipline is asking, for each feature: if we launched without this, would the answer to our question change? If no, it’s v2.
How to brief so the estimate means something
Vendors pad estimates in proportion to ambiguity, so a precise brief is the cheapest thing you can produce. Provide:
- The one workflow, written as steps a user takes.
- Every user type, and what each can do.
- Every external system to be integrated, with documentation links.
- Volume and performance expectations in the first year — honestly, not aspirationally.
- Any regulatory constraint that applies.
- What already exists — designs, a brand, a backend, a prototype.
- The hard deadline, if there is one, and what it’s tied to.
A vendor who receives that and still quotes without asking questions is guessing. A vendor who comes back with ten sharp questions is the one to take seriously.
Fixed price or time and materials?
For a genuinely well-specified MVP, fixed price is reasonable and shifts scope risk to the vendor. For an exploratory product where you expect to learn from users, fixed price converts every discovery into a change request and turns the relationship adversarial.
A common compromise works well: a short, fixed-price discovery producing designs, an architecture, and a real estimate — then an iterative build. You pay a small amount to replace guesswork with a number.
Frequently asked questions
How long does an MVP take? For a focused single-workflow product with a decided scope, a small team measured in a few months is typical. The variable that moves the timeline most isn’t team size — it’s how quickly you make decisions.
Can I build an MVP with no-code first? Often, and you should consider it. If the question is “will anyone use this,” a no-code prototype answers it far cheaper. Move to custom code when the constraint is real: scale, integrations, unusual logic, or ownership.
Why is my quote so much higher than my friend’s? Almost always scope, user roles, or integrations — rarely rate. Compare the assumption lists, not the totals.
Should I pay for discovery? Yes, if the alternative is a fixed price built on guesses. A paid discovery that produces a real estimate is cheaper than the change requests it prevents.
Internal links: #6 developer cost by region, #8 fixed price vs T&M, #1 engagement models, /contact. External references: the original “minimum viable product” framing in Eric Ries, The Lean Startup, for the learning-first definition. CTA: “Send us the workflow and we’ll come back with questions before a number.” → /contact