Guides What an MVP costs to build, and how to spend less

A minimum viable product is the smallest version of your product that can prove or disprove the idea it rests on. Its cost is set by how small you are willing to make it. Most MVP budgets overrun for one reason: the first version tries to be the finished product.

What decides the cost

• User roles: a product with one type of user is far smaller than one with customers, providers and administrators.
• Core flows: the handful of things a user must be able to do for the idea to be tested.
• Integrations: payments, maps, messaging, identity checks or an existing system — each is work beyond the screens.
• Platforms: a responsive web app, a cross-platform mobile app, or separate native apps.
• Regulated data: health, financial or children's data brings security and compliance work from day one.
• AI or blockchain features: worth including only when they are the thing being tested.

How to make the first version smaller

• Write the one assumption the MVP must test, and cut every feature that does not help test it.
• Do by hand what can be done by hand: an admin approving sign-ups is cheaper than building the rules.
• Use proven services for login, payments, email and hosting instead of building them.
• Launch on the web first unless the idea depends on something only a phone app can do.
• Leave the admin dashboard plain; your users never see it.

Fixed price or monthly team

For an MVP with a written scope, a fixed price gives you a known number and puts the risk of estimating on the builder. The scope document matters most: list what is out as well as what is in, and agree how changes are priced. Once the MVP is live and the work becomes a stream of changes, a monthly team usually suits better than a series of small fixed quotes.

The cost after launch

Hosting and third-party services are usually small at MVP scale. The larger cost is the changes you will want once real users arrive — which is the point of building an MVP. Plan a budget for the months after launch rather than spending everything on the first release.

Code you can build on

An MVP should be small, not disposable. Ask for code in your own repository, automated tests on the parts that handle money or data, and a short handover document. If the idea works, the next team — yours or ours — builds on it instead of starting again.