What a software MVP really costs, and where the money goes

Ask five software teams to price the same idea and you can get five very different answers. That is not always because someone is overcharging. Usually each team has imagined a different product, made different assumptions and included or excluded different work. Understanding what drives cost is the best way to compare quotes fairly and to spend your budget where it matters.

This guide deliberately avoids quoting typical prices, because rates and scope vary enormously by region and team. Instead it explains where the money goes, so you can ask the right questions.

What an MVP is for

A minimum viable product is the smallest version of your product that lets real users get real value, so you can learn whether the idea works. It is not a cheap version of the full vision. Its job is to test your riskiest assumption, such as “employers will pay to post vacancies” or “people will book cleaners through an app”, as quickly and cheaply as possible.

That definition is the most powerful cost control you have. Every feature that does not help test the core assumption can wait.

Cost is mostly team time

For custom software, the main cost is the time of the people building it: product, design, development, testing and project management. Total cost is roughly the time needed multiplied by each person’s rate. So the real question is what makes the work take longer.

The main cost drivers

Number of user types

Each type of user, such as buyers, sellers and administrators, needs its own journeys, permissions and screens. A two-sided marketplace is often close to building two products.

Number of screens and flows

Each screen needs design, building, responsive layouts, empty and error states and testing. Ten simple screens can be less work than three complex ones with many states.

Integrations

Payments, maps, email, calendars, accounting systems and third-party APIs each bring setup, edge cases and testing. Poorly documented or unusual integrations can be among the most unpredictable parts of a project.

Platforms

A web app, an iOS app and an Android app are three surfaces to design, build, test and release. Cross-platform tools reduce this, but launching on one platform first is cheaper still.

Design depth

A clean interface built from a proven component library costs much less than a fully custom visual design with bespoke illustrations and animations. Both are valid; they are different budgets.

Data, compliance and security

Handling payments, health data, financial data or children’s data brings extra legal and security requirements. Migrating data from an existing system also takes careful work.

The work cheap quotes leave out

• Admin tools: someone needs to manage users, moderate content, issue refunds and see what is happening.
• Quality assurance: testing across devices and browsers, and regression testing before each release.
• DevOps: environments, automated deployments, backups, monitoring and security updates.
• Project management and communication: planning, demos, decisions and documentation.
• Content: copy, legal pages, onboarding emails and help text.
• Launch support: fixing the issues real users inevitably find in the first weeks.

Running costs after launch

The build is only the first bill. Plan for ongoing costs from day one:

Where an MVP budget typically goes

Every project differs, but most MVP budgets are spread across the same phases. Knowing them helps you see whether a quote is balanced:

1. Discovery and scoping: agreeing the problem, users, core flows and what is out of scope.
2. Design: user flows, wireframes, visual design and a clickable prototype.
3. Build: frontend, backend, integrations and admin tools, usually the largest share.
4. Testing and hardening: QA, fixes, performance and security checks.
5. Launch: deployment, monitoring, store submission and early fixes.

How to spend less without building the wrong thing

• Cut user types: launch with one side of a marketplace handled manually by your team at first.
• Do things that do not scale: a spreadsheet and a person can replace a complex automated workflow until volume justifies it.
• Buy rather than build: use proven services for authentication, payments, email, search and content management.
• Launch on one platform: usually a responsive, installable web app, adding native apps once demand is proven.
• Use a design system: a polished component library gives a professional look at a fraction of the cost of fully custom design.
• Prioritise ruthlessly: sort every feature into must-have for the test, nice-to-have and later, and only fund the first group.

Questions to ask every team

1. What exactly is included, and what is explicitly excluded?
2. What assumptions did you make about users, platforms and integrations?
3. Who will work on the project, and how much of their time?
4. How will we see progress, and how often?
5. What happens when we want to change something mid-project?
6. What will it cost to run and maintain after launch?
7. Who owns the code, designs and accounts when the project ends?

We give fixed-scope proposals that list every assumption and exclusion, so you can compare them fairly. If you have an idea and want to understand what it would take to test it, a free discovery call is the best place to start.