What drives MVP development cost, and what to cut first

What drives MVP development cost is rarely what buyers expect. The instinct is to count screens or features. Screens are cheap. What makes a minimum viable product expensive is everything behind them: the systems it has to talk to, the number of people who see different things, the rules it has to obey, the devices it has to run on, and the data it inherits. The same idea can need a small team for four to six weeks or a larger team for many months, depending on those factors alone.

This playbook goes through the drivers one at a time, then covers what to cut, what never to cut, and how to get an estimate you can plan against. There are no prices here. Rates vary too much between teams for a number to mean anything. Effort, in weeks and team shape, travels better.

Why screen counts mislead

Two apps with twelve screens each can differ in effort several times over. One shows data from its own database to a single type of user. The other pulls records from a legacy ERP, writes back to a payment provider, hides half its fields depending on who is logged in, keeps an audit trail for a regulator and runs as native apps on two platforms.

The screens look similar in a mockup. The work behind them is not. When comparing quotes, the first question to ask of each vendor is what they assumed about the things you cannot see.

The cost drivers, ranked by how often they surprise people

Driver	Why it adds effort	Early question to ask
Integrations	Each external system brings its own authentication, data format, error cases, rate limits and test environment	Is there a documented API and a sandbox we can use in week one?
Roles and permissions	Every role multiplies the states each screen can be in, and all of them need testing	How many user types see genuinely different things?
Compliance and security	Audit trails, consent, encryption, data residency and evidence for auditors	Which regulation applies, and who signs it off?
Platforms	Each additional platform adds build, testing, release process and ongoing maintenance	Does the core job need a native mobile capability?
Design depth	Custom interaction design and user testing take real weeks; a design system takes more	Is the interface the differentiator, or the workflow?
Data migration	Old data is dirtier than anyone admits, and every mapping decision needs a business owner	How much history does release one actually need?
Scope clarity	Vague requirements get priced as contingency or discovered as rework	Could two vendors estimate this within a sensible margin of each other?

Integrations

This is the driver that surprises people most. A well-documented modern API with a sandbox environment is a contained piece of work. A legacy system with no API, a file drop at midnight and one person who understands the format is not, and the uncertainty is the expensive part rather than the code.

Integration effort also sits outside your control. If the other system’s team cannot give you test credentials for three weeks, your project waits three weeks. We now ask for sandbox access in the first week of every engagement, before we know exactly what we will call.

Roles and permissions

One user type is simple. Three is a different product. A partner portal where administrators, regional managers and partners each see different records, with some fields editable by only one of them, needs a permission model designed before the first screen, and every screen tested as every role.

Our work on a network of around two thousand partner organizations taught us that permission design is the part to get right first. We wrote up what that involved in role-based access for a two thousand partner network.

Compliance and security

Healthcare, financial services and anything touching personal data in the EU add work that is invisible in a demo: audit logs, consent capture, encryption at rest and in transit, data residency, retention rules, and the documentation an auditor will ask for. None of it is optional once the regulation applies. Ask who in your organization signs off compliance and involve them in week one, not week six.

Platforms

A responsive web app is one codebase for every device and ships without app store review. A cross-platform mobile framework such as React Native or Flutter adds a second delivery channel with its own release process. Separate native iOS and Android apps add a third codebase and roughly double the mobile testing.

Go mobile first only when the core job genuinely needs something the browser does poorly: camera, offline use, background location, or push notifications that users rely on. Many MVPs launch on the web and add a mobile app once usage shows which part of the product people use on the move.

Design depth

There is a large range between a clean interface built from an existing component library and a custom interaction design tested with users several times. Both are legitimate. The right choice depends on whether the interface is where you compete. For an internal operations tool, a well-organized standard interface is usually right. For a consumer product in a crowded category, design is the product, and cutting it saves weeks while losing the point.

What we would not cut is user testing of the core flows. Testing a clickable prototype costs days. Discovering a broken flow after it has been coded costs the launch.

Data migration

If the MVP replaces a spreadsheet, a legacy system or a previous product, somebody has to move the data. Old data has duplicates, missing fields, free text where there should be a code, and records that break rules the new system enforces. Each of those needs a decision from someone who knows the business, and those decisions are slow.

The most effective cut is to question how much history release one needs. Often the answer is active records only, with the archive available read-only in the old system for a few months.

What to cut

Cutting well means removing work that can be added later without rework, and keeping the foundations that are expensive to retrofit.

Admin interfaces. In the first release, configuration can be done by the delivery team on your behalf. Building screens for settings that change twice a quarter is poor use of early weeks.

The second platform. Launch on the web or on one mobile platform, and let usage decide what comes next.

Integrations that can be manual for a month. If data from another system changes weekly, release one gets a CSV import and release two gets the API.

Secondary user roles. If a role exists mainly to view reports, give those people an export for now.

Reporting and dashboards beyond the one metric that tells you whether the product works.

The third feature. Discovery usually finds a few things that matter and a longer list that someone wants. The longer list waits, each item with a written reason.

What never to cut

Discovery. Skipping a week of user research to gain a week of build produces a product that needs rebuilding. We have not seen an exception.

Automated tests and a deployment pipeline. These are the reason the second release is cheaper than the first.

Monitoring and error reporting. If you cannot see it fail, you cannot fix it.

Security basics. Proper authentication, secrets kept out of the code, dependencies checked. A penetration test can come later; the fundamentals cannot.

A data model designed from the flows. A poor one is the most expensive thing to change after launch.

The detail of how this plays out sprint by sprint is in an AI-assisted MVP in four to six weeks.

How to get a reliable estimate

An estimate is only as good as the scope it is based on. Four steps move a number from guess to plan.

Pay for discovery first

A firm estimate needs designed flows, a data model, an integration inventory with documentation, the list of roles, the compliance requirements and a written list of exclusions. That is about a week of discovery for most products. Vendors who give a firm price without it are either adding a large contingency or planning to read scope narrowly later. Our view on how contract model follows from discovery is in fixed price vs time and materials.

Ask for estimates as ranges with named assumptions

A single number hides uncertainty. A range with the assumptions that would move it, such as “assumes the CRM sandbox is available by week two” or “assumes two roles, not four”, tells you where the risk is and what you control.

Estimate in team shape and weeks

Ask for the team, by role, and the number of weeks. A typical narrow MVP team is a product consultant, a designer, two or three full stack developers and a QA engineer, over four to six weeks. Seeing effort this way makes quotes comparable across vendors in a way that a headline number does not, and it shows you whether a quote is missing someone, often QA.

Compare assumptions, not totals

When quotes differ widely, put the assumption lists side by side. The gap is almost always explained by something one vendor included and another did not. Resolve that, and the quotes usually converge.

A quick self-assessment

Before asking anyone for a number, answer these:

1. How many distinct user roles see different data?
2. Which external systems must the first release talk to, and does each have a usable API and test environment?
3. Which regulation applies, and who signs off?
4. Web, one mobile platform, or both?
5. Is the interface where you compete, or the workflow behind it?
6. What existing data must be migrated before launch, and who owns it?
7. Could you write the three things release one must do on one page?

If you can answer all seven, you are ready for an estimate. If three or more are unclear, you are ready for discovery, and any firm number you receive now will be mostly contingency.

When you should not build yet

If you cannot yet name the user and the one job the product does for them, no development budget will fix that. Spend a few weeks talking to potential users, or test demand with a landing page, a manual service or a no-code prototype before engaging a development team, us included.

If the product is mostly an existing SaaS tool with your logo on it, buy the tool. Custom development earns its effort when the workflow is specific to your business, or when it is the thing you sell.

When those questions have answers, a narrow first release built properly is usually the cheapest way to learn what the full product should be.