MVP cost: what changes the price

The biggest differences in MVP quotes usually come from scope: how many user roles, integrations and complete flows are included, and who handles design, testing and deployment. Compare those assumptions before comparing totals. Here is a way to turn an idea into a brief that developers can price consistently.

Eight things that change the price

1. Complete flows, not single screens. A report over existing data may take less work than a checkout with refunds and payment retries. Count the full flow, including its failure cases, rather than the number of buttons on a screen.

2. The number of user roles. A product with one kind of user is simpler than one with customers, staff and an admin, each seeing different things.

3. Integrations. Payments, email, calendars, maps and other services each need setup, testing and handling of failures. Payments in particular need care.

4. Authentication and accounts. Sign-up, login, password reset, email checks and permissions are standard, but they take time and must be done properly.

5. Data complexity. Few simple records are cheap. Many connected record types, reports and imports are not.

6. Design. If you have finished designs, the developer builds from them. If you don’t, someone has to design, or the product will look plain.

7. Platforms. A web app is one build. A web app and an iOS app and an Android app are several.

8. Quality expectations. Tests, monitoring, backups, security checks and documentation. They’re easy to skip, and a cheap quote often leaves them out.

What a quote should list

A useful quote names:

• The features included, in plain words.
• The features that are explicitly not included.
• What design is assumed.
• What happens at the end: who owns the code, where it is hosted, whether there is a handover.
• How changes are handled, and what they cost.

If a quote is one line with one number, ask what is inside.

A short brief to send with your request

Write down these answers before asking for an estimate:

• The user: who will use the first version, and what they need to finish.
• The main flow: where the user starts, what they do and what counts as success.
• Accounts and data: who can see or change what, and which information must be stored.
• Integrations: payments, email or other services the flow depends on.
• What already exists: designs, content, a codebase or a prototype the developer can inspect.
• The release boundary: what has to work at launch and what can wait.

Send the same brief to each developer. Ask them to list their assumptions and what they left out, so you can compare like for like.

If you already have a prototype, built by hand or with an AI tool, find out whether it can be fixed before you pay for a new build. Fix or rebuild covers how to decide, and taking over an existing app is how I’d start on one.

Fixed price, hourly or monthly

Fixed price suits a clear scope. It protects your budget, but only if changes are priced separately and the scope is written down.

Hourly suits work that will change as you learn. Ask for a weekly cap and a short weekly report, so it stays visible.

Monthly suits ongoing work after launch: a set number of days a month for fixes and improvements.

A common pattern is a small paid scoping step first, then a fixed price for version one, then a monthly arrangement.

How to get a number you can trust

1. Write down the one thing the MVP must prove. A sentence, not a document.
2. List features and rank them. Mark which are essential for that one thing.
3. Cut the list in half. Then ask whether the product still proves its point.
4. Ask two or three people for a quote on the same list. Compare what is included.
5. Ask what they would drop. A developer who suggests removing features is thinking about your outcome.

How to keep the cost down without making a bad product

• One user role, one main flow.
• Common tools, which are easier to hire for later.
• Use a service for what is not your business, such as payments or email sending, instead of building it.
• Keep the visual styling simple without cutting accessibility, clear errors or a usable main flow.
• Launch to a small group first.

What not to cut: security basics, backups, and the ability to deploy a change safely.

Where to start

If you want a number for a specific idea, the most useful thing you can send is the one sentence that the MVP has to prove, plus a short list of must-have features. I work on MVPs as one developer from first commit to launch, and I quote after one conversation, listing what is and isn’t included.