How much does it cost to build an MVP? Real market ranges

What the public data shows

The numbers here are typical ranges seen on Clutch profiles of agencies selling to US clients. In August 2026 we went through 22 of them and recorded three things from each: the hourly band they publish, the project minimum they state, and the budget buckets attached to their client reviews.

• Disclosed project budgets concentrate in two buckets. $50,000 to $199,000 is the most common, and $10,000 to $49,000 is second. Together they cover about two thirds of the reviews where the client allowed the size to be shown. These are engagements of every size, not just first builds.
• Eighteen of the 22 state a project minimum of $10,000 or more, and $10,000 is by far the most common single answer. A smaller group opens at $25,000 or $50,000.
• Every one of the 22 publishes an hourly band inside $25 to $99, split roughly evenly between the lower and upper halves of that range. Twenty-one of them are agencies based in Latin America or Eastern Europe, and the twenty-second is a US sourcing consultancy.

Three reasons not to anchor too hard on those numbers

Reviews skew toward finished, successful projects, and clients can choose to hide the budget. The visible sample tilts toward the larger and prouder end of what these firms build, so the real distribution almost certainly sits lower than the published one.

A bucket labeled $50,000 to $199,000 is wide enough to hold four very different products. It tells you the order of magnitude and nothing finer than that.

And a stated minimum is a filter, not a price. It exists to keep small inquiries out of the sales pipeline, which means it says more about who a firm wants to talk to than about what a build costs.

What the data is good for is calibration. If a quote comes back at $4,000 for a product with user accounts, payments and an admin area, it sits below the floor that 18 of those 22 firms will even open a conversation at. That doesn't automatically make it a scam, and three of the firms we read do publish minimums under $10,000. It does mean something is being traded away, and you should find out what before you sign.

The six things that actually move the number

Scope conversations tend to circle around feature lists. These are the variables that move a quote the most, roughly in order of impact.

• How many user types there are. One role is a form. Three roles with different permissions, different views, and an admin who can act on someone else's behalf is a different system, and every rule multiplies what has to be built and tested.
• Whether money moves through it. A single card payment is small. Subscriptions with upgrades, proration and failed-payment recovery are several times that. Marketplace splits, payouts to third parties and identity verification are several times that again, because the difficulty stops being code and becomes rules, edge cases, and money you can genuinely lose.
• How many outside systems it has to talk to. Each integration is a second product you don't control, with its own authentication, rate limits, outages, and a sandbox that behaves differently from production. Two integrations cost more than twice one, because their failures start interacting.
• Whether the design already exists. Building on a component library with sensible defaults is fast. A custom visual identity with illustrated empty states and motion is a separate project that happens to ship inside yours.
• Whether it has to be a native mobile app. A responsive web app reaches everyone from one codebase. Native iOS and Android means two builds, two review processes, release timing you do not control, and push notification plumbing on both sides.
• What has to be true on day one about scale and uptime. Software for 200 pilot users and software that has to survive a launch on its first morning are priced differently. Most first versions only need the first one, and paying for the second before you have users is the most common way to overspend.

Notice what is missing from that list

Screen count. It is what buyers count, it is what makes a proposal look thorough, and it correlates poorly with cost. Ten simple views over one clean data model are cheaper to build than three views sitting on top of four systems that disagree about who the customer is.

When you are comparing quotes, comparing feature counts will mislead you. Compare what each vendor says about roles, money and integrations. If a proposal is silent on all three, it was not written for your project.

What fixed scope protects you from, and what it does not

Two contract shapes dominate this market: hourly, sometimes called time and materials, and fixed scope. The choice decides who carries the risk of the estimate being wrong.

Hourly puts that risk on you. If the work was estimated at 400 hours and takes 700, you pay for 700. It is an honest way to price genuine uncertainty and it works well when you have an engineering lead of your own who can tell whether hour 500 was well spent. Without that person, hourly is a budget with no ceiling and no one qualified to look inside it.

Fixed scope moves the risk to the vendor. They absorb the gap between estimate and reality, which is exactly why a fixed quote carries a margin for being wrong. You pay somewhat more in exchange for a number you can plan a fundraise or a launch around.

Now the part that usually goes unsaid. Fixed scope only protects you if the scope document is specific. The phrase user management in a contract isn't a scope. It is a word that gets argued about in week six, and the argument goes to whoever wrote the sentence. Fixed scope also makes mid-build changes expensive by design, because the original number was calculated without them. If you expect to change direction weekly, a fixed contract will feel like a cage and hourly will genuinely serve you better.

The practical version for a first release: fix the scope of a block small enough to write down completely, ship it, put it in front of real users, and quote the next block separately once you know something you do not know today.

The mistakes that make an MVP cost more than it should

None of these are exotic. They are the ones we see most often when a project arrives already halfway built and over budget.

• Agreeing to features in calls and never writing them down. Anything settled verbally and not documented is a feature you'll pay to build twice.
• Building the admin panel before building the product. Internal tooling feels productive and no customer has ever paid for it. A spreadsheet and a database client cover the first few months fine.
• Rebuilding what a service already does. Authentication, email delivery, file storage, search, payments. Each is a service costing a few dollars a month and weeks of engineering to reproduce badly.
• Buying the cheapest available hour. A $25 hour that produces code your next team refuses to work in is the single most expensive line in the project. You just pay it later, as a rewrite, at full price.
• Launching with twelve features so the launch feels serious. Every feature added before you have users is a bet placed with no information. Cut to the one job the product exists to finish.
• Accepting a delivery with no handover. Code without documentation, without the accounts in your name, and without a structure a stranger can read isn't an asset. It is a dependency on the people who built it.

How to get a number you can trust within a week

Vendors give vague answers partly because they get vague questions, and you can fix your half of that in an afternoon. Ask for four things back in writing: what's included, what it costs, when it is delivered, and what happens to the price when you change your mind. A vendor who can't produce those four inside a few days will not get more precise once money is involved.

Here's what to send them:

• One sentence naming who the user is and what job they finish inside your product.
• The three screens that matter, even hand-drawn on paper. Not twenty.
• Every external system it must talk to, and which of those you already have accounts and API access for.
• What day one looks like: 20 pilot users, or a public launch with traffic. It changes the answer.
• The budget range you're working with. A vendor who needs that hidden in order to sell you something is exactly the one you want to filter out early.

The short answer

Agency-built projects sold to US clients visibly transact somewhere between $10,000 and $199,000, across engagements of every size and not just first builds, and the declared market floor sits around $10,000. Where you land inside that range is decided by user roles, money movement and integrations, not by how many screens you sketched.

We deliberately left our own prices out, for the same reason we would distrust anyone else's on a page like this. Without knowing what you are building, any published number would be wrong for almost everyone reading it. What we can publish is the process: tell us what you are building and you get a written scope, a fixed price and a delivery date within 24 hours. If the honest answer is that you do not need custom software yet, that's what you'll hear instead.

The detail on the work itself

• MVP development →

  How we scope and price a first version, and what actually ships inside it.

• SaaS development →

  For when the first version has users and needs billing, roles and an admin behind it.

Frequently asked questions