Search this question and you will find ranges from roughly $10,000 to $200,000 or more, usually presented in a table sorted by "simple, medium, complex." The ranges are not wrong. They are just unusable, because the thing that determines where you land is not complexity in the abstract — it is a series of decisions you have not made yet.

So rather than adding another table, here is what actually moves the number.

What the published figures say

For context, since it is reasonable to want a starting point. Industry surveys published in 2026 put a simple single-platform MVP at roughly $10,000–$40,000 over two to four months, a medium build with real integrations at $40,000–$100,000 over three to six months, and a complex multi-platform product at $100,000–$200,000 or more.

The same sources put hourly rates at roughly $80–$150+ in the United States, $70–$130 in Western Europe, $35–$70 in Eastern Europe, $30–$60 in Latin America, and $20–$45 across much of Asia. Engagement model matters similarly: freelancers around $10,000–$40,000, agencies $30,000–$150,000+, an in-house team $80,000–$200,000 once you account for salaries during the build.

Design, quoted separately, tends to run $5,000–$25,000 for an early-stage product, with boutique agencies around $15,000–$40,000 and senior specialist firms considerably above that.

Treat all of these as orientation, not estimates. A twenty-fold range is a sign that the question is underspecified, not that the market is irrational.

The six things that actually set your number

1. How many user types you serve

This is the single largest multiplier and the one most often missed. A marketplace serving buyers and sellers is not one product with two audiences. It is two products that happen to share a database — separate onboarding, separate interfaces, separate empty states, separate support.

Cutting from two user types to one is usually the biggest saving available, and the most resisted, because it feels like cutting the business model. It is not. It is sequencing the business model.

2. Whether the scope is a journey or a list

A build scoped as a completed user journey has a natural end. A build scoped as a feature list does not, and grows by roughly a third during delivery because every conversation adds an item that sounds reasonable.

This is why two teams quoting the same "MVP" can differ by a factor of three without either being dishonest. They are pricing different documents. More on why in how to scope an MVP when the deadline is fixed.

3. What you are integrating with

A payment provider and an email service are close to free in effort terms. A banking API with a certification process, a healthcare records system, a legacy enterprise platform with no documentation and a contact who replies weekly — those are not features, they are dependencies with their own schedules.

The cost here is rarely the code. It is the waiting, and waiting is billed.

4. What data you hold

Regulated data changes the whole build. Consent flows, audit trails, retention rules, data residency, access controls, documentation, and quite possibly an external assessment. Published figures for compliance work on early products run anywhere from $18,000 into six figures depending on the regime.

If this applies to you, find out in week zero. It is the most common source of a budget doubling in month three.

5. Who is on the team, and how many

Rates vary geographically by a factor of five, but team size matters more than rate at this stage. A small senior team is usually cheaper in absolute terms than a larger mixed one, because coordination cost rises faster than headcount and because senior people delete more work than they add.

At MVP scale, the most expensive engineer is the one who builds something that should not have existed.

6. How much is decided before you start

The cheapest budget lever available, and it costs nothing but discomfort. Every open question — the pricing model, which user type comes first, what happens in the failure case — stalls the build and gets resolved in a meeting that could have happened before the engagement started.

Teams that arrive with a settled journey, a chosen user type, and a price point routinely spend a third less than teams with the same product and an unresolved plan.

The costs that do not appear on the quote

This is where budgets actually break.

The unglamorous build. Account recovery, error states, empty states, an admin view, staging environments, monitoring, email deliverability, a privacy notice, cookie consent. None of it is on the feature list and all of it is required. In the builds we run it regularly accounts for a quarter to a third of total effort.

Content. Someone has to write every label, every error message, every email, every legal page. If you have not budgeted time for this, it lands on a developer at the worst possible moment and it shows.

Running it. Hosting, domains, certificates, third-party tools. Modest at MVP scale — commonly $50–$500 a month — but it starts at launch and never stops.

Keeping it alive. Maintenance is conventionally estimated at 15–25% of the original build cost per year. Dependencies need updating, providers deprecate APIs, browsers change. A product with no maintenance budget degrades quietly.

The second version. This is the big one. An MVP that succeeds generates work — the things users asked for, the things that broke under load, the second user type you deferred. Founders who spend their entire raise on version one have no capacity to respond to what version one taught them, which wastes the learning they just paid for.

A reasonable planning rule: whatever the build costs, hold roughly the same amount again for the six months after launch.

Where AI has and has not changed the number

Some published estimates now claim AI-assisted development reduces cost by 30–40%. Our experience is that the saving is real but narrower than that figure suggests, and it is concentrated in specific places: scaffolding, boilerplate, test data, format conversion, first drafts of routine interfaces.

It does not much help with the parts that dominate an early build — deciding what to make, integrating with an uncooperative third party, or the unglamorous list, where being subtly wrong is expensive and everything has to be verified anyway. Review time is real time, and it scales with how much was generated.

The honest summary: it compresses the middle of a build noticeably and the beginning and end very little. We have written more about where that line falls in where AI speeds up creative work.

How to get a quote you can compare

If you are speaking to several teams, these are the questions that make quotes comparable:

  • What user journey does this price cover, end to end? If the answer is a feature list, ask again.
  • What is explicitly excluded? Content, legal pages, analytics, admin tooling, deployment.
  • What happens when we run out of time? The answer should be that scope gives way, not the date.
  • What are we doing manually at launch, and who does it?
  • What does the first three months after launch look like, and what does it cost?
  • Who owns the code, the accounts, and the data? Get this in writing before anything starts.

A team that answers these precisely will usually quote higher than one that does not, and cost less by the end.

On not publishing a price

We do not publish a fixed MVP price, and it is worth saying why rather than leaving it as an omission. The number is genuinely determined by the six factors above, and most of them are unknown at first contact. A published figure would either be high enough to be safe — which is a poor deal for the straightforward projects — or low enough to be attractive and then revised, which is worse.

What we do instead is scope first: a short piece of work that establishes the journey, the user type, the integrations and the manual steps, and produces a fixed number for the build with the exclusions written down. It is a smaller commitment than a build, and it is useful even if you then take it to someone else.

If you are trying to budget for a first product and the range you have been given spans an order of magnitude, the fastest way to narrow it is to settle the scope rather than to collect more quotes. That is the conversation we start with in web app development — and quite often it ends with a smaller build than the one that was originally described.

Common questions

How much does an MVP cost in 2026?

Published industry ranges put a simple single-platform MVP at roughly $10,000–$40,000, a medium build with real integrations at $40,000–$100,000, and a complex multi-platform product above $100,000. Where you land is set less by category than by how many user types you serve and how much was decided before the build started.

Is it cheaper to hire a freelancer or an agency?

Freelancers are cheaper per hour and commonly quoted at $10,000–$40,000 for an MVP, against $30,000–$150,000 for agencies. The difference narrows once you account for who handles scoping, launch readiness, content and project management — work that exists either way and lands on the founder if nobody else owns it.

What percentage of an MVP budget goes to design?

There is no reliable industry split, and quoted design ranges of $5,000–$25,000 for early-stage products overlap heavily with total build budgets at the low end. A more useful framing: design cost tracks the number of distinct user types and screens, which is the same thing that drives engineering cost.

Why do MVP quotes vary so much?

Usually because the teams are pricing different documents. A build scoped as a completed user journey has a defined end; one scoped as a feature list does not. Two honest quotes for the same "MVP" can differ threefold without either being wrong.

How much should I keep back for after launch?

Roughly the same again as the build. An MVP that works generates immediate work — the things users asked for, what broke under load, the second user type you deferred. Spending an entire raise on version one wastes the learning version one just produced.

Sources and further reading