MVP development: what to build first and what it costs

A minimum viable product (MVP) is the smallest version of an application that lets you test the riskiest assumption behind it with real users. It is not a mock-up and it is not a cut-price product: it works, but it is limited to one complete user journey. That is why its cost depends less on a rate card than on how many features you are willing to postpone.

So the useful question is not "how much does an MVP cost?" but "what must be in it?". Here is a practical way to decide, what usage data says about features, how the budget is really built, and the mistakes that turn a first release into an endless project.

What an MVP actually is

Eric Ries popularised the term in The Lean Startup (2011), describing the MVP as the version of a product that lets a team learn the most about its customers with the least effort. Three consequences follow, and they are often forgotten.

An MVP is a learning tool. It answers a specific question. Will customers pay for this service? Will the field team give up paper forms for this app? Without a written question, you do not have an MVP, only an unfinished application.

An MVP is used for real. A demo or a prototype shows the product; an MVP puts it in the hands of users, on their own data, in their actual work. That is what sets it apart from the other early-stage deliverables, compared side by side in our guide to prototypes, MVPs and proofs of concept.

The scope comes from the assumption. You do not trim a feature list at random. You keep what is needed to test the assumption, and nothing else.

Why cut so hard: what usage data says

Instinct says "add it, just in case". Usage data says otherwise. In 2019 the software vendor Pendo analysed anonymised data from 615 customer subscriptions in its Feature Adoption Report: 80% of the features in the average software product were rarely or never used, and 12% of features generated 80% of daily usage.

Read it with two caveats. It is a vendor study of products already on the market, and what counts as a "feature" depends on how each customer set up the tracking tool. The order of magnitude still holds a lesson: most of the features that feel essential before launch end up barely used. In an MVP, every feature you leave out saves budget and time, and removes something you would otherwise have to maintain.

A method for deciding what goes in

1. Write the assumption in one sentence. "Technicians will log their jobs on a tablet instead of paper." "Accounting firms will pay a monthly fee for this client dashboard." Everything else follows from it.
2. Map one journey, end to end. From the moment the user arrives to the result they came for. An MVP that covers half of three journeys proves nothing; one that covers a whole journey proves something.
3. Test every feature against one question. Without it, can the user still get to the end? If yes, it waits.
4. Do things manually where you can. Invoicing early customers by hand for three months costs far less than an automated billing module built before anyone has agreed to pay.
5. Set the success criterion before building. Weekly active users, a share of jobs logged in the app, a first paying customer. Without a threshold, the MVP never ends: it just grows.

Applied to a typical case, an equipment booking platform shared by the branches of a company, the sorting looks like this:

Market MVP or internal MVP: two different tests

A SaaS MVP tests a market assumption: will customers who have never heard of you find enough value to pay? Success is commercial (sign-ups, conversion, first subscriptions), so payment tends to come early. The components specific to SaaS, such as separate customer accounts, subscriptions and round-the-clock operation, are covered in our article on the cost of building a SaaS platform.

An internal MVP tests adoption: will the team use it instead of what they use today? It covers one process, one department, sometimes one site. It is often the right way out of a shared spreadsheet that nobody trusts any more, as discussed in our article on replacing Excel with a custom application.

What drives the cost of an MVP

There is no standard price for an MVP, for the same reason there is no standard price for an application: two projects described in the same words can have nothing in common. The drivers are well known:

• the number of user journeys kept (ideally one);
• the integrations needed from day one, such as accounting, ERP or payments;
• the existing data that must be migrated;
• the number of user roles and permission levels;
• running costs: hosting, backups, monitoring.

These factors are detailed in our article on what a custom business application costs, and their effect on the schedule in our guide to how long it takes to build an app.

One thing is not negotiable: an MVP reduces features, not quality. It handles real data, so it must be secure, backed up and compliant like any production system. A fragile MVP does not test your assumption, it distorts it: users reject the crashes, not the idea.

Then comes the way you pay for it. With a fixed price, the amount is set before the first line of code. With a subscription, you do not pay for the development, only a monthly fee covering hosting, maintenance and updates; LPR Studio then remains the publisher and operator of the application, and the rights of each party are defined case by case in the contract. The three models are described on our offers page.

The mistakes that turn an MVP into an endless project

The MVP that is really a full version 1. Every feature is there, "just in a simple form". It costs nearly as much as a version 1 and teaches you nothing more.

No success criterion. Without a threshold agreed in advance, every piece of user feedback becomes a feature request, and the MVP keeps growing without ever reaching a conclusion.

Building for an imaginary future. Designing an architecture for ten countries before the first customer burns the MVP budget. The opposite is a mistake too: throwaway code that must be rewritten the day the assumption is confirmed. The right balance is clean, standard, maintainable code on a narrow scope.

Skipping the stage where you see it. Finding out mid-development that a screen does not match how people actually work is expensive. Seeing it on a prototype before any code is written costs almost nothing, which is why the prototype comes first in our approach.

Where to start

The cheapest moment to cut scope is before development, while the screens only exist as a demonstration. At LPR Studio, that visual prototype is free and presented in a video call within 5 working days: screens, user journeys and realistic data. It is where we decide together what goes into the MVP and what waits, and the validated prototype becomes the specification for the fixed price. We also publish and run our own software, Izi-Devis and Tubissime, so choosing between "now" and "later" is part of our daily work.