MVP development cost: how to compare quotes without guessing

Three PDFs in your inbox, all for the same app. One says $6,000. One says $14,000. One says $32,000, and it has a nicer cover page.

You could split the difference and pick the middle one. Plenty of people do. It feels sensible, and it tells you nothing, because those three numbers may not be prices for the same thing.

The real cost of an MVP (a minimum viable product, the smallest version real customers can use) is the price of reaching one written scope, including testing, launch and handover. Until every developer quotes that same scope, comparing totals is guesswork. This article gives you the brief, the message to send, the worksheet and the contract terms that fix that.

Featured image: AI-generated editorial illustration of a fictional founder, not a client photograph. The quotes in this article are made-up examples, not market prices. I also sell this kind of work, so treat me as an interested party and check my reasoning.

How much does MVP development cost?

No honest single number exists, because "MVP" can describe a two-screen booking tool or a regulated payments product. Published guides do give ranges, and they're useful as a rough sense of scale. Read them knowing who wrote them.

Both are development firms, and I'm one person in the same trade. None of us is a neutral witness. I couldn't find an independent, current dataset of MVP prices, so I won't hand you an "average cost" with a confident face. A range that runs from $15,000 to $150,000 can't tell you whether your $14,000 quote is fair anyway.

Why do early estimates swing so much?

Early estimates swing because the job itself isn't decided yet. Construx's white paper on the Cone of Uncertainty puts estimates at the first-idea stage at up to four times too high or too low, a 16x range from top to bottom. It also says the only way to narrow that range is to make decisions that remove the variability, including what you won't build.

Don't treat 16x as measured physics. Laurent Bossavit's history of the idea shows the original ranges were set by judgement, and later project data disputed the neat shape. The practical point survives the argument: a vague request produces numbers that are far apart, and more quotes won't fix that. A better brief will.

A quick way to sanity-check any quote

Divide the price by the hourly rate, and ask whether that many hours could do the job. Picture a $6,000 quote at $30 an hour. That buys 200 hours, or five 40-hour weeks for one person, to cover design, building, testing and launch. Maybe that's plenty for a small tool. Now you can ask the right question out loud.

For a US reference point, the Bureau of Labor Statistics gives a median software developer wage of $135,980 in May 2025. That works out to about $65 an hour across 2,080 work hours (my arithmetic), or about $31,000 in wages for one developer over 12 weeks. It's a wage rather than a quote, and rates differ hugely by country and experience. It does show why a very low local quote needs an explanation.

What should an MVP quote include?

A useful quote names the work, the proof that it's finished and everything it leaves out. Each row below is something you can ask about without knowing how to code.

The exclusions line matters most. A developer who lists what they won't do is showing you where the edges of the job are. An empty exclusions section doesn't mean everything's included. It usually means nobody has discussed it yet, and you'll discuss it later, at a less friendly moment.

Costs that usually sit outside the quote

Some costs belong to you whichever developer you pick, so check they haven't quietly vanished from the plan:

• Apple: the Apple Developer Program costs $99 a year.
• Google Play: a $25 one-time registration fee.
• Running costs: hosting, email, payment fees, error tracking and any AI usage. The running-cost section of the vibe coding checklist shows how usage fees grow with customers.
• Your own time: someone has to answer questions, approve screens and test each milestone. That's usually you.

Mobile rules that add scope nobody mentioned

If your MVP is a mobile app, store rules can add real work, so ask each developer to confirm these are priced.

• Account deletion. Apple's guideline 5.1.1(v) says an app that supports account creation must offer account deletion within the app. Google Play requires an in-app path and a web link for requesting deletion.
• Login options. Apple's guideline 4.8 can require an extra privacy-focused login option if you use a third-party login such as Google for the main account. The guideline lists exemptions.
• Closed testing. Google Play personal developer accounts created after 13 November 2023 must run a closed test with at least 12 testers opted in for at least 14 days before applying for production access. That's two weeks on your timeline, and you have to find the testers.

Still deciding on platforms? The article on shipping to both app stores from one codebase covers that tradeoff.

How do you compare MVP quotes fairly?

Send every developer the same one-page brief, then adjust their answers to that scope before you look at the totals. The conventional advice is to collect three to five quotes. Fine, once you've got the brief. Without it, you're collecting five answers to five different questions.

Step 1: write a one-page brief

Your brief needs five things, in plain words:

1. Who it's for: the customer, and the one problem this version solves.
2. What they can do: five to ten sentences that start "A customer can..." or "An admin can...".
3. What it won't do yet: this list saves more money than any negotiation, because every line removes work from every quote.
4. What it connects to: payment provider, email, calendar, existing data.
5. Your limits: launch date, budget range, and anything regulated, such as health data.

Should you share your budget? I would, as a range. A good developer can then tell you what fits inside it and what to cut, which is more useful than a polite number that ignores your reality. Yes, some people will quote up to the ceiling. Your worksheet will catch that.

Step 2: send everyone the same message

Copy this, and fill in the brackets:

Please quote against the attached one-page brief. So I can compare fairly, please list: the price and estimated hours for each feature; design, testing and launch setup as separate lines; your hourly rate for changes; how long you'll fix bugs after launch and what counts as a bug; who will do the work; what you're excluding; and who owns the code and accounts at the end. If you think something in the brief is wrong or unnecessary, please say so. I'd value that. I'm hoping to decide by [date].

That last-but-one request does quiet work. The developer who tells you to drop a feature, and explains why, has just shown you how they'll behave once you're paying them.

Step 3: fill in this worksheet

Copy this table and add one column per quote. For each row write included, excluded, or the price to add it. Ask the developer for that price in writing, so you aren't inventing it yourself.

The worksheet checks whether quotes cover the same work. It doesn't check quality, so it can't tell you who writes better software. For that, you still need to talk to them.

A worked example: from a 5x gap to 1.3x

Here's an invented example, showing how a huge price gap can shrink once the scope is equal. Imagine a web app for booking and paying for appointments. The founder's brief asks for a 60-day bug-fix period and no mobile app. The founder gets the extra prices in writing from each developer.

The headline gap was 5.3 times. The real one is 1.3 times.

Quote A was never the cheap one. It was the same price as B, with more of the bill arriving later, when you've got less bargaining power and a launch date breathing down your neck. Quote C wasn't greedy either. It was answering a bigger question than the founder asked, and it may still deserve the job if those developers are stronger.

Twenty years selling capital market products to people who read the fine print taught me to treat a headline fee this way. Nobody sensible compares two products on the front-page number. You ask what's inside, what's charged later and what it costs to get out.

Your numbers won't land this neatly. If quotes stay far apart after adjusting, one of them still understands the job differently, and that's your next phone call.

Should you choose a fixed price or pay by the hour?

Choose a fixed price when the scope is written down and unlikely to move, and hourly with a cap when you're still finding out what the product should be. Fixed price feels safer. It isn't automatically. It moves the argument from "how many hours?" to "was that in scope?", and a vague brief loses that argument every time.

US government buying rules offer a useful principle, though they don't govern your contract. FAR 16.601 allows time-and-materials contracts only when the work can't be estimated with reasonable confidence. It says they provide "no positive profit incentive" for labour efficiency, and it requires a ceiling price. Procurement officers worked this out at public expense, so you may as well borrow it: if you pay by the hour, set a cap and watch the hours.

How do you define "done" without reading code?

Write each feature as a test you could perform yourself: who does what, and what should happen. "Payments work" starts an argument. This doesn't:

Then tie money to those tests, with each payment due when its tests pass. One simple shape is a deposit at the start, then payments at the first working version, at acceptance on a test site and at launch. The percentages are yours to negotiate. Holding a meaningful share until launch keeps everyone's attention on the last 10% of the work, which has a known habit of taking longer than the first 90%.

Before real customers arrive, the launch checklist for AI-built and fast-built apps gives you tougher tests for permissions, payments and recovery. They apply whoever wrote the code.

Who owns the code when the project ends?

Don't assume paying for the code means you own it. Get a signed written assignment that names the work, the rights, the duration and the territory. This is general information rather than legal advice, so have a lawyer check the final contract.

The default rules can surprise you:

• United States: the Copyright Office's Circular 30 lists nine categories of commissioned work that can be "made for hire", and software isn't named among them. A commissioned work outside those categories fails the test, even if the contract uses the words.
• India: the Copyright Act makes the author the first owner, with exceptions such as employment. Section 19 requires an assignment to be in writing and signed. If it doesn't state a period, it's deemed to be five years. If it doesn't state a territory, it's presumed to cover India only.

Read that India rule again. A contract that simply says "the client owns the code" could leave you with a five-year, India-only right to your own product, if a court applies those defaults. Two extra lines in the contract avoid that.

Who should own the accounts?

You should, from the first day. Ownership of the code won't help much if the live product sits in someone else's account. Open these in your company's name, then invite the developer as a team member:

• Domain name and DNS settings
• Code repository
• Hosting and database
• Payment provider, which is where your money and customer records live
• Email sending and analytics
• App store accounts

For Apple, organisation enrolment needs a legal entity and a D-U-N-S number, and your organisation's name appears as the seller. Individual enrolment shows your personal legal name. Sort this early, since it takes time and can't be rushed the night before launch.

What does the first year cost after launch?

Ask for a named list and not a percentage. You'll often see 15 to 20% of the build cost suggested for annual maintenance, as in the TeaCode guide above. I can't trace that figure to independent data, and it scales with the wrong thing: a cheap build with a payment system can need more care than an expensive brochure.

Ask each developer to price these for year one: hosting and tools at your expected customer numbers, security and dependency updates, monitoring, backup restore checks, a response time when something breaks, and the hourly rate for new work. The web app appliance guide explains why a product needs this care in the first place.

Signals that should make you pause

Pause when the risk moves to you and nobody says so out loud. None of these proves a developer is bad. Each one deserves a direct question before you pay.

The last one surprises people. A developer who disagrees with you before you've paid is giving you a free sample of the working relationship. A friendly yes to everything can get expensive around week six.

Finally, some things not to do: don't choose on the total alone, don't let the cheapest quote fund a bigger feature list, and don't ask developers to work for free on "a quick paid-later prototype" to prove themselves. Pay for a small, well-defined first piece if you want proof. It's the cheapest test in this whole article.

Try this: a 45-minute quote review

You can run this today with quotes you already have, or with one quote and a blank column for comparison.

1. Ten minutes: write your "A customer can..." list and your "won't do yet" list.
2. Fifteen minutes: copy the worksheet, and mark every line in your quote as included, excluded or unclear.
3. Ten minutes: turn your three most important features into acceptance tests you could perform yourself.
4. Ten minutes: send your questions on every "unclear", using the message above.

It worked if you can answer three questions without opening the PDF: what's excluded, what happens if the work runs late, and who owns the accounts. If you can't answer them yet, you've found what to ask before you sign. The reply will also tell you something. Clear answers within a couple of days are a good sign. Irritation at being asked is useful too, since you've learned it before paying anyone.

Frequently asked questions

How much should I budget for an MVP?

Budget for the adjusted quote, plus a reserve for changes and your first year of running costs. Published ranges are too wide to set a budget for your product, so get real numbers for your brief. I'd hold back a reserve because you'll learn things once customers arrive, and 20% is a sensible starting point in my judgement, not an industry benchmark. If the total doesn't fit, cut features rather than cutting testing.

Why is one MVP quote so much cheaper than the others?

Usually it covers less work, assumes something different, or uses a lower hourly rate, and the worksheet shows which. A lower rate can be perfectly fair, especially across countries. Less scope is the one to watch, because those costs tend to come back as change requests. Ask the developer to price each missing line in writing, then compare again.

Is a freelancer or an agency better for an MVP?

Either can work, and the better choice depends on the job and the people. A freelancer often costs less and gives you direct access to the person writing the code, though you depend on one person, so handover matters more. An agency gives you more roles and cover, though you should confirm who does the work. Use the same worksheet for both.

Can I build the MVP myself with AI and skip quotes?

Yes, for testing an idea, and it can be the cheapest way to learn whether anyone wants the product. The risk rises once you take payments, hold private data or depend on it for income. At that point, pay for a review against a launch checklist, which may cost far less than a rebuild. What you built also makes a strong brief for any developer you hire later.

Should I pay for a discovery phase?

Pay for one when you can't yet write the one-page brief, or when the product carries real technical risk. Ask for the output in writing: a scope, acceptance tests, a risk list and a fixed quote for the next stage. Make sure you own it and can take it to another developer. If a firm won't let you do that, you've bought a sales process.

How long does it take to build an MVP?

It depends on the scope, so ask for a timeline with a checkable result at each stage and not just a final date. Include your own approval time, third-party setup and any store review or testing period. Google Play's 14-day closed test, for example, is a fixed wait for personal accounts it applies to. A plan with no room for feedback isn't fast, only optimistic.

The cheapest quote is the one you understand

Write the one-page brief before you ask anyone else for a number. It costs an hour, it narrows every quote you'll receive, and it stays useful whichever developer you pick, including if that developer isn't me.

If you'd like a second pair of eyes, send me your brief and the quotes and I'll tell you what I'd ask each developer, even if the answer is that one of them is a better fit. You can also see how I approach web app builds.