tely
Blog
Product24 juin 2026

What actually drives the cost of an MVP

0

The same product can cost five times more or less. The seven factors behind the gap, and the ones you can act on.

“How much does an app like mine cost?” No honest answer fits in one number, and not out of commercial caution: two products that look alike from the outside can differ by a factor of five. Here are the seven factors that explain the gap. Four are yours.

1 · The number of roles.

The most underestimated factor. An application with one type of user is a product. With three — a client, a supplier, an administrator — it's three interfaces, three permission sets, three journeys to test, and interactions between them that multiply the edge cases. Going from one role to three doesn't triple the effort: it multiplies it further, because the complexity lives in the crossings. You can act on this: pick one role for v1.

2 · Who holds the truth.

An application that displays data is simple. An application that becomes the source of truth — where things are entered, corrected, validated — demands audit trails, concurrency handling, reconciliation rules, a recovery strategy. Barely negotiable: it's a property of the problem, not of the product.

3 · Third-party integrations.

Every integration adds a dependency that will fail one day. Payments, accounting, shipping, calendars: you have to handle errors, timeouts, retries, reconciliation when things drift apart.

The cost of an integration isn't in the happy path, it's in the failure paths.●

A vendor who prices an integration at two days has priced only the happy path. You can act on this: defer the ones that don't block the first sale.

4 · The regulatory constraint.

A product handling personal information of Quebec or European residents requires granular consent, automatic purging, export, access logging, data residency. Planned at scoping, this constraint is marginal. Discovered in sprint 10, it forces a migration. It's the factor whose cost depends most on when you raise it.

5 · Bilingualism.

Designed in from the start: a modest premium, mostly design time. Added after launch: schema migration, query rework, search reindexing, mockup revision, document rebuild. You can act on this — once, at the beginning.

6 · The decision-maker's availability.

The least technical factor and one of the most decisive. A blocking question left unanswered for four days is a team building on an assumption — sometimes a wrong one, and then it has to be undone. Without a decision-maker available every week, count on roughly 30% more effort. It isn't a contractual penalty: it's redoing work built on guesses. You can act on this, and it's free.

7 · The quality required.

A prototype to test a hypothesis and a product that will take payments next month don't have the same requirements for tests, logging, backups or fault tolerance. Both are legitimate. What isn't legitimate is paying the price of the first while expecting the second.

The question to ask any quote.

“What isn't included in this number?” A serious quote answers in three minutes with a precise list. A vague quote answers “everything is included”, which is never true — and you'll find out which parts weren't in sprint 6, when it's too late to compare.

What we don't do.

We don't price a build we haven't scoped. A number quoted without a scope is a wrong number — either it commits you to a sum that won't hold, or it's inflated out of caution and you pay for the vendor's uncertainty.