How much does an MVP cost? What actually drives the price
What makes an MVP more or less expensive, how we estimate one, and where you can cut scope without paying for a rewrite six months later.
“How much does an MVP cost?” is the first question on nearly every call we take. The honest answer is “it depends”, which is no help when you are writing a budget. So here is what it depends on, in the order it matters.
1. How many questions the MVP has to answer
A good MVP answers one question: will people pay for this?, will clinics actually use online booking?, can a sales rep close an order without a phone call? Every extra question adds screens, roles and edge cases.
The most expensive MVPs we have seen were not technically hard. They were trying to validate five ideas at once.
What you can do: write the question in one sentence. If you need the word “and”, you have two MVPs.
2. Who has to use it
One type of user is cheap. Two types who interact — customer and supplier, patient and clinic — roughly doubles everything: flows, notifications, permissions. An admin panel for your own team is a third small product.
What you can do: for the first weeks, the admin side can be a spreadsheet or an existing tool. Build it once you know what you actually do by hand.
3. Which platforms
Web, iOS and Android used to mean three teams. With React Native and Expo we ship all three from one codebase, but each app store has its own review process, and testing on real devices takes time.
What you can do: if your users sit at a desk, start with the web. If they live on their phones, start with an installable web app and move into the stores once you have traction.
4. Integrations
Payments, invoicing, ERP, calendars, identity checks — each integration is a small project with its own documentation, limits and surprises. It is also where estimates go wrong most often, because it depends on a system nobody in the room controls.
What you can do: for every integration, ask: “What happens if we do this by hand the first 50 times?” Sometimes the answer is “nothing bad”.
5. How finished it needs to be
An MVP for 20 invited users is not the same as one launched to the public. Security, performance, accessibility and compliance (GDPR, health or financial data) all matter. We never drop them entirely, but how far we take each one depends on who will use the product.
How we estimate
We don’t quote a price after the first call. We give a range and suggest a short, fixed-price discovery. At the end you have:
- the question the MVP validates, in writing;
- the main flows as a clickable prototype, tested with a few real users;
- the architecture and integrations, with risks marked;
- a fixed scope, a fixed date and a fixed price for the build.
If something new comes up during the build, we cut scope to keep the date, not the other way round. A date that moves three times costs more than any feature.
Where not to cut
Three things stay in even the smallest MVP, because they are cheap at the start and very expensive later:
- The code in your repository from day one. Not at the end.
- Automated tests on the flows that make money — sign-up, payment, checkout.
- Error monitoring. Your first user who hits a bug won’t e-mail you. They will just leave.
Skip them, and the cheap MVP turns into the expensive rewrite.
In short
The price of an MVP depends less on the technology than on how many decisions are still open. The clearer you are going in, the lower it gets. If you like, we can run this exercise on your idea in a 30-minute call.