MVP development cost: what belongs in the estimate

A useful MVP estimate describes the product you will receive, the assumptions behind the work, and the responsibilities that remain after release. The headline price is only one part of that decision.

There is no single budget for every minimum viable product. A first release with one user role and an existing data source is different from a product with billing, several permissions, and an integration nobody has checked.

Start with one complete user journey

Write down who the user is, where they begin, what they do, and the result they receive. Include the important failure cases. If a user pays and the product cannot provide the result, what happens next?

This journey is the starting point for MVP development. It is also the basis for deciding what can wait. A feature is not essential merely because it appears in a competitor's product.

For example, a scheduling product might first let a customer choose an available slot and receive confirmation. Staff administration, cancellation behavior, time zones, and notifications still need decisions. A large analytics dashboard may be able to wait.

Split the estimate into reviewable work

Ask the developer to identify the work in each area:

• Discovery and design: resolve requirements, map the journey, and agree acceptance criteria.
• Application development: interfaces, business rules, account access, data, and the selected workflows.
• Integrations: external APIs, credentials, payment handling, and recovery when a provider fails.
• Verification: test the important behavior, including errors and permissions.
• Release: deployment or store submission, environment configuration, access handover, and operating instructions.
• Ongoing ownership: maintenance, support, provider charges, and subsequent changes.

These are budget components, not six mandatory contracts. Their purpose is to show what the proposal includes.

Identify assumptions before they become extra work

An estimate should say which systems already exist, who can grant access, what data is available, and what still needs a technical check.

If an integration has no usable test environment, do not treat its behavior as settled. If a prototype works only on its creator's computer, leave room to establish the build and release process.

Ask how uncertain work will be investigated and how the estimate changes when an assumption is wrong. A fixed scope still needs a process for changes.

Compare the same release in each proposal

Two proposals are comparable only if they cover the same behavior and responsibilities. Ask each provider:

1. What can a real user complete at the end?
2. What is explicitly excluded?
3. Which acceptance criteria will demonstrate that the work is complete?
4. Who owns the source, accounts, data, and deployment?
5. What happens after the first release?
6. Which decisions must I make before work can proceed?

A lower quote that excludes release, tests, or handover may describe a different product.

Keep running costs separate

Development is only part of the budget. Hosting, email delivery, monitoring, storage, paid APIs, payment fees, and maintenance may continue after launch. Not every product needs every provider.

Ask for the expected services and the assumptions behind their use. Third-party prices can change; obtain current prices from the providers before committing to a budget. Define who pays each bill and who owns each account.

For a subscription product, review SaaS development. For a native app, review mobile app development cost.

Send a brief that makes an estimate possible

Include the intended users, one complete journey, any existing prototype, integrations, required deadline, and your budget constraint. A budget band helps a provider propose a realistic scope; it does not replace an estimate.

Use the custom software planning guide to prepare the brief.

Email AL+ about your MVP. Include what the first release must let a user do and what you need to learn from it.