Engineering Practice
Cost & Budgeting3 min read
What an MVP actually costs, and what moves the number
Nobody can quote an MVP from a one-line description. Here are the seven variables that decide the figure, and how to move each one before you ask for a price.
Working on something like this?
Get an estimateThe short version
- Screens are the worst predictor of cost. Integrations, roles, and compliance are the best.
- Every integration with a system you do not control is a schedule risk, not just a task.
- Compliance is not a line item. It changes how every other line item is built.
- An estimate given without a discovery call is a sales tactic, not a number.
Every agency has been asked to price an MVP from a paragraph, and every honest answer starts the same way: it depends on things the paragraph does not mention.
That is not evasion. The same feature list can differ by a factor of five depending on what it connects to and who is allowed to see the data. What follows is what actually moves the number, so you can shape the project before you ask anyone to price it.
The seven variables that set the price
1
Integrations you do not control
Each connection to an external system — a payment provider, an ERP, an EHR, a carrier API — carries unknowns: undocumented behaviour, sandbox environments that differ from production, and approval processes measured in weeks. Two integrations are not twice one integration; they are the two plus the interaction between them.
2
Number of distinct user roles
One role is a product. Four roles is four products sharing a database, each with its own screens, permissions, and edge cases. This is the single most underestimated multiplier we see.
3
Compliance load
HIPAA, PCI DSS, or SOC 2 requirements do not add a task at the end. They change how authentication, logging, data storage, and hosting are all built, from the first commit.
4
Design starting point
Building against an existing design system is materially cheaper than designing from scratch. If there is no brand, no component library, and no decided interaction model, that work exists whether or not it is in the estimate.
5
Data migration
Moving existing customers, orders, or records into the new system is frequently the largest single line item on projects that mention it late. Legacy data is never as clean as the person describing it believes.
6
Real-time and offline behaviour
Live updates, collaborative editing, and offline-capable mobile apps each change the architecture rather than adding a feature. Ask for them at the start or accept they are a second project.
7
Who operates it afterwards
A build handed to an in-house team needs documentation and knowledge transfer. A build nobody will own needs a support agreement. Neither is free, and leaving it out of the estimate does not make it disappear.
What does not move it as much as you think
- Screen count. Twenty simple screens against one data model cost less than six screens spanning four systems.
- Choice of framework. React versus Vue, Postgres versus MySQL — these matter for maintenance and hiring, not for the first build's price.
- Design polish, up to a point. Getting from ugly to clean is cheap. Getting from clean to distinctive is where design cost concentrates.
How to make it cheaper without making it useless
Cut breadth, not depth. Fewer roles, fewer integrations, manual processes behind the scenes for the first fifty customers. What you must not cut is authentication, error handling, a payment path if you charge, and enough analytics to see what people did — scoping an MVP covers where that line sits.
The cheapest integration is the one you defer. If a connection to an accounting system can be a weekly CSV export for six months, make it one and spend the saving on the part of the product customers actually touch.
When the number is genuinely large
Sometimes the honest estimate is bigger than the budget. That is information, not a failure. The right responses are to narrow the scope until it fits — one lender deferred 41 of 96 items in writing and still hit its pilot — to phase it so the first release proves the case for the second, or to decide the project is not viable. All three are better outcomes than starting something that runs out of money at seventy percent.
If you want the wider version of this — costs across full custom builds rather than first versions — see what custom software development costs. If you are ready to price a specific idea, our MVP development page sets out how we scope and what the estimate covers.
Working through this on a real project?
Tell us what you are building. You will get a scoped estimate and an architecture you own, not a capability deck.
Common questions
The range is wide enough that a single figure would mislead you. What sets it is integrations with systems you do not control, the number of distinct user roles, compliance requirements, whether design starts from scratch, and whether existing data has to be migrated. A focused product with one role and no external integrations sits at one end; anything touching payments, health data, or a legacy system sits far up the other. Any firm quoting before asking about those five things is guessing.
Usually because they are quoting different things. One has assumed you have designs, another has included them. One assumed a manual admin process, another built the admin screens. Compare the assumptions rather than the totals — where they differ is where the real scope conversation is.
Fixed price works when scope is genuinely fixed, which for a first version it rarely is. What usually serves better is a fixed budget with flexible scope: the number is capped, and you decide throughout what makes the cut. We compare both models in detail in our piece on fixed price versus time and materials.
The day rate is lower and the total is not always. What decides it is how many attempts the work takes and how much time you spend specifying, reviewing, and correcting. A team that gets the payment integration right once at a higher rate frequently costs less than a cheaper team that gets it wrong twice.