What an MVP Costs, and What Drives the Number

Why the Same Idea Gets Five Different Prices

Ask five suppliers to price "a marketplace app" and you will get five different products. One assumed a web app, one assumed native mobile on both platforms. One assumed you already have the designs. One included payments, one did not. One priced the version that handles refunds, disputes and payouts, because they have built a marketplace before and know those are not optional.

The cheapest quote is frequently the one that understood the least. That is not always true, but it is true often enough that a suspiciously low number is a prompt to ask what has been assumed rather than a reason to celebrate.

Before comparing prices, make the assumptions comparable. Ask each supplier to list what they have included and, more revealingly, what they have excluded.

The Eight Things That Actually Move the Cost

Platforms. One web application is the baseline. Add native iOS and Android and you are close to multiplying the front-end work, unless you accept a cross-platform approach. Deciding you need apps because competitors have apps is one of the most expensive unexamined assumptions in this whole process.

Integrations. Every external system is a negotiation with someone else’s API, their sandbox, their edge cases and their outages. Payments, identity, accounting, CRM, shipping, a legacy internal system with no documentation. Integrations are consistently underestimated, and the legacy one with no documentation is worth several of the modern ones.

Who the users are. An internal tool for twenty colleagues can be plain and a little awkward. A consumer product competing for attention cannot. The same functionality costs materially more when strangers have to understand it without training.

Whether design exists. Working from your finished designs is cheaper than designing from scratch. Working from finished designs drawn by someone who has never designed software is sometimes more expensive than starting fresh.

Regulation and data sensitivity. Health, financial or children’s data brings audit trails, retention rules, access control, consent handling and documentation. GDPR applies to your prototype exactly as it applies to your product. This is real, unavoidable engineering, and it is invisible in a demo.

Roles and responsibilities. Multiple user types multiply the surface area. Admin, customer, supplier and support are four products sharing a database, not one product with a dropdown.

Content and data migration. Moving years of existing records out of a legacy system, cleaning them and reconciling them is frequently a larger piece of work than the new application, and it is the item most often left out of a quote entirely.

Timeline. Compressing a schedule costs more than the same work done at a natural pace, and past a certain point adding people makes it slower rather than faster. A deadline tied to an event or a funding round is a legitimate reason to pay the premium; a deadline set because sooner feels better is not.

What Is in the Price Besides Writing Code

Typing the features is perhaps half of it. A credible quote also covers discovery and technical design, testing, a deployment pipeline, the infrastructure it runs on, security basics, and the fixing of things found once real people use it.

Then there are the running costs that are not in the build price at all: hosting, third-party services, domains and certificates, app store fees, and any AI or messaging usage that bills per call. Ask for an estimate of the monthly figure at launch and at ten times your expected volume. Nobody volunteers this, and it surprises people.

Budget for what happens after launch. A build with nothing left for iteration is a product frozen at the moment it first met a user, which is the moment you learn the most.

How to Genuinely Reduce the Cost

Cut users before you cut features. Serving one type of user properly costs far less than serving three badly, and it is a much easier decision to reverse.

Do the unscalable thing manually at first. If a human can run the matching, the approval or the onboarding by hand for the first fifty customers, the software to automate it can wait until you know the process is right.

Use boring, well-supported technology. Novel stacks cost more to build, more to hire for and more to maintain, and your users cannot tell.

Buy instead of building anything that is not your differentiator. Authentication, payments, email, analytics, scheduling. Building these yourself is a well-trodden way to spend the budget on parts nobody will pay you for.

Web first. A good responsive web application reaches everyone immediately, with no app store review and no second codebase. Go native when you need something the browser genuinely cannot do, not before.

Bring decisions quickly. The cheapest thing a client can do is answer questions the same week. Idle time is billed on time and materials and padded for on fixed price.

What Actually Blows Budgets

Scope added quietly. Rarely one large change; usually thirty small ones that each seemed trivial. Track them somewhere visible with their cost attached, or the overrun arrives as a surprise at the end.

Decisions that stay open. An unresolved question does not pause the project, it makes people build around it, and building around it twice costs more than deciding once.

The integration nobody investigated. Where a project doubles, an undocumented third-party system is very often involved. Find these in discovery, not in month four.

Design finalised late. Changing a layout is cheap on paper and expensive once built. Front-end work redone because the design moved is the most avoidable rework there is.

Ambiguity about what "done" means. Agree, in writing and before the build, what will be true for the project to be complete. Both sides think this is obvious. They rarely mean the same thing.

How to Read the Quote You Have

A single number for a multi-month build is a wish, not an estimate. Look for phases, ranges, or stated confidence, all of which reflect how software is genuinely estimated.

Check for the boring items. Testing, deployment, infrastructure, security, browser and device support, accessibility, data migration. A quote without them is not cheaper, it is smaller.

Look for a risks section. Every real project has three or four things that might go wrong, and a supplier who has thought about yours will say what they are.

Ask what is excluded, and get it in writing. This question produces more useful information than any other, and the reaction to it tells you something too.

Ask what they would remove to save a quarter of the budget. A partner will have an opinion and will explain the trade. A vendor will tell you everything is essential.

Getting a Real Number for Your Own Idea

There is no useful average, because the range for anything described as an MVP spans more than an order of magnitude, and an average of that tells you nothing about your case.

The reliable route is a short, fixed-price discovery: a week or two producing a technical approach, a scoped plan and a costed estimate you can take elsewhere. It converts the largest unknown into a small, bounded spend, and you own the output whether or not you continue with the supplier who produced it.

If you would rather just talk it through first, that is free. Tell us what you are trying to build and we will tell you the shape of the number, the parts that worry us, and whether we think you should build it at all.