MVP Development Cost in 2026: What Actually Drives It

A founder asked me last year what an MVP would cost, and when I said I could not tell him yet he thought I was stalling.

He had described a marketplace with two sides, payments, and "a simple admin panel", although each hides a decision that moves the number by a factor of three: a simple admin panel could be a table with search, or the thing his operations team lives in eight hours a day, with bulk actions, audit trails, and a way to undo a mistake at 4pm on a Friday.

He got four quotes - roughly 8k, 22k, 45k and 120k - and all were honest but for four different products, because he had not decided which he wanted and none made him decide before naming a price.

The number you get back is mostly a guess about you

When someone quotes your MVP, they estimate how much software needs to exist, how much uncertainty they are absorbing, and how much of their time you will consume outside building, although the first is what everybody focuses on and usually the smallest driver.

The second is why quotes vary: a developer facing a vague brief either pads the number for what they cannot see or quotes the optimistic reading and renegotiates later, so the padded quote is often honest while the cheap one is frequently a prototype estimate with a product's name on it.

If you take four days to answer a question, the build stalls four days and the developer absorbs it on a fixed-price engagement, which is why experienced people price for the two-week feature that takes seven because nobody can decide what "verified" means - the third cost nobody tells you about.

The fastest way to reduce your quote is not to negotiate but to remove ambiguity before anyone opens an editor.

What actually eats the budget

I have shipped six iOS apps in the last nine months alongside client work and rebuilt an operations platform for a property inspection business with over 25,000 properties and more than 60,000 inspections, and in both the feature code is rarely the expensive part.

Integrations. Every third-party system has an opinion about how the world works, and none match yours: the property platform's source system shared a rate limit of roughly 60 requests a minute for everyone touching that account, including the client's daily operations, so the backfill had to stay at 40 a minute, leaving headroom but turning hours into days, which is a scheduling reality that belongs in the estimate.

Then come failures: 429s that must honour Retry-After, transient 5xx responses that look like bugs, and two processes holding OAuth credentials, where one refreshed the token and silently invalidated the other. It failed during a read-only verification run, before writes, by luck rather than design, and the fix was a rule for which process can refresh - the cost was an afternoon plus the rule.

Data you already have. This is the most underestimated line item, by far: importing records is easy, but proving them correct is the job. On the same platform, the media migration had three paths for a single image - it might already be in old storage, be adoptable by filename, or need downloading from the source system - and filename matching fails when two properties have kitchen.jpg, so we report collisions rather than silently attach the wrong photograph to the wrong property for two years.

The system holds over 17 million file attachments and more than 4 TB of media; conceiving it was easy, but verifying it was slow.

Authentication and permissions. This is never one sentence: who sees what, acts for whom, what happens when someone leaves, whether an admin can impersonate a user for support, and whether it is logged, because each is a data-model fork and getting it wrong is a migration rather than a patch.

The admin surface. Your team needs to unblock a customer without calling you, with search that works, data correction, and a record of who corrected it, because if you build this badly you create a support dependency on the developer that you pay for forever.

The operational tail. Restored backups, error reporting that reaches a human, a reversible deploy, and rate limiting so a crawler cannot take you down - it is perhaps a week at the start, and the week founders cut first.

Three shapes, and what they actually cost

These are arithmetic, not a market survey: senior contract engineers in Western Europe broadly charge 400 to 850 EUR a day, depending on positioning and country, and I use 600 as the middle. Multiply by weeks, adjust for your region, and treat the result as a starting point rather than a quote.

Prototype, 2 to 4 weeks, roughly 5k to 12k. One happy-path flow, real UI, fake or hardcoded edges - good for an investor or testing whether anyone wants it, but not a product that will become one, so you will throw most away, which is fine if you knew it.

Launch-ready MVP, 6 to 12 weeks, roughly 15k to 35k. Real accounts, data, and deploys, so a user can correct a mistake, you can correct theirs, and you find out when it breaks - this is what most people mean by MVP, and what most cheap quotes do not describe.

Workflow replacement, 10 to 20+ weeks, 30k to 90k+. You are replacing a spreadsheet or old tool with migration, permissions, operations UI, and a cutover plan. The property platform sits here: software was maybe half the effort, while the rest was moving fourteen years of history without losing any, and at the first shape's price this shape will fail or become the first shape with a different name.

AI changed the cost of code, not the cost of judgement

Writing code is faster now - I ship more than I used to, and six apps in nine months show it, so anyone claiming otherwise has not been paying attention.

But integrations, data correctness, permissions, and operations are questions of what is right, not what is possible, and generation speed does not change the 60-a-minute rate limit, the human choice on a filename collision, or the two processes fighting over token refresh.

The cost moved to verification: generated code still needs careful review, so if someone says AI makes their MVP 5x cheaper, ask for their review process because that tells you whether they are fast or just quick. Industry surveys consistently show that most developers do not fully trust the output without checking it, and the prototype end has come down while workflow replacement has barely moved because typing was never the hard part.

What I cut, and what I never cut

Cut freely: second dashboards, notification preference centres, anything multi-language before you have retention in one language, reporting before adoption, and any settings screen written on the assumption users want control, because they do not yet.

Cut carefully: search can start dumb, onboarding can be a manual email, and billing can be an invoice by hand for the first ten customers, because manual is fine early - fastest to build and the most honest way to learn what to automate.

Never cut: the permission model, backups you have restored, an audit trail on anything financial or destructive, and error reporting, because they are cheap at the start and brutally expensive to retrofit as structural work. An audit trail added after a year gives you a start date and a gap, not last year's history.

I would rather ship half the features with a permission model I trust than everything with one I am hoping about.

The brief that gets you a real number

Write this before asking for a quote to get better, closer numbers.

1. Who is the first user, specifically. A job title, not a segment.
2. The hero workflow in 5 to 8 steps, as they would describe it.
3. What "done" means for v1, in three bullets that could be checked by someone else.
4. Which integrations are required at launch, and which are wishes.
5. What data already exists, where it lives, roughly how much of it there is, and whether it is any good.
6. What is non-negotiable: compliance, a date, a security constraint.
7. Who decides, and how fast they can decide.

The last point is the one nobody writes down, and it most reliably predicts whether a project lands on time; for point six, get API rate limits before quotes, because a throttle nobody checked can turn a two-week import into five and engineering skill cannot make that smaller.

Reading the quote you get back

Signals a quote is real: annoying questions, named exclusions, data-migration line items, and written scope-change terms, while signals it is not are one number with no breakdown, no existing-data mention, a timeline requiring instant decisions, everything "included", or no request to see the system you are replacing.

Ask before hiring what would make this take twice as long: an immediate, specific answer means experience, while "Nothing much" does not. For what happens after you pick someone, technical due diligence covers how to check the work is real; if you are still deciding between a contractor, an agency and hiring, that comparison is here.

I build products end to end, and I quote after I have seen the data, not before. If you want a number for something specific, my CV and rates are here.