Estimate an MVP by user journeys, integrations and acceptance criteria. Separate validation work, production essentials and features you can defer.
Hypothesis
Complete journey
Pilot & evidence
An MVP budget should buy evidence about a product assumption. Name the user, the task they need to complete and the behaviour that would justify another investment. A clickable prototype tests comprehension; a working MVP tests use with real data and operational constraints. Do not compare their prices as though they deliver the same evidence. The smallest useful release still needs a complete journey, including failures and support.
Start with the scope, not a headline price
| Option | What you are paying for | What changes the estimate |
|---|---|---|
| Prototype | Interaction design and a demonstration of the proposed journey. | Useful for feedback, but it does not prove production reliability or real integrations. |
| Working web MVP | One primary journey with identity, persistence, deployment and basic operational visibility. | Roles, payments, uploads and external APIs each introduce exception paths to implement and test. |
| Pilot with customers | Onboarding, support tools, monitoring and controlled access for a defined pilot group. | Migration, contractual requirements and existing customer data can outweigh the visible feature list. |
Costs to include before you compare quotes
- Authentication includes recovery, permissions and session behaviour. A login screen alone is not a complete identity scope.
- Integration estimates should cover sandbox access, API limits, retries and duplicate requests, not just one successful API call.
- Reserve time to observe the pilot and act on evidence. Shipping consumes the build budget; learning requires someone to review usage and feedback.
Where to simplify — and where to keep the work
Reduce the number of journeys before removing basic data protection, error handling or deployment checks. A manual back-office step can be a sensible pilot compromise if its owner and capacity are explicit. Record that compromise so it does not quietly become a permanent dependency as customer numbers grow.
Turn the scope into a budget
Ask for hours by work package: discovery, design, implementation, testing and release. Multiply each package by its agreed rate, then add external services and an explicit allowance for unresolved risks. Compare quotes against the same acceptance criteria, currency and tax treatment. Calendar weeks are not person-weeks: two engineers working together change the effort and coordination cost. For ongoing work, choose a monthly period. Keep one-off setup separate from recurring fees, and ask who approves changes before additional work starts.
A brief that gets you a useful estimate
- Write one user story from entry to a completed outcome, with an observable success measure.
- List must-have roles, data, integrations and failure cases; put deferred features in a separate list.
- Define the pilot size, release owner and a decision date for continuing, changing direction or stopping.
Check your own budget assumptions
Labour budget
Hours × rate × (1 + contingency / 100)
Planning arithmetic using your inputs, not a quote or a market price. Excludes tax, hosting, licences and other third-party costs. Use one currency throughout; changing it does not convert amounts.
Frequently asked questions
Does a fixed launch date guarantee a fixed MVP price?
No. A date constrains calendar time, not the amount of work. Agree a minimum outcome and a ranked backlog, then state what can be deferred if an integration or product assumption changes. A fixed price needs similarly explicit assumptions and change control.
What is the smallest useful MVP scope?
One complete journey that tests a business assumption with real users. Include access control, support and measurement needed to run that journey responsibly.
Can a prototype replace a production MVP?
A prototype can test comprehension and demand. It does not prove reliability, data handling or integration behaviour. Budget separately for a product used by customers.
How can we prevent the MVP budget from growing?
Name a decision maker, separate essential work from experiments and approve changes against the original hypothesis. Review working software at short checkpoints.
What should be included in the handover?
Repository and infrastructure access, deployment instructions, test coverage for the core journey, known limitations and ownership of ongoing support.
Bring the scope. We will help make it buildable.
Share the user journey, integrations and launch constraints. We can clarify the scope and prepare an estimate with assumptions and exclusions.
Further reading
SaaS development cost: budget beyond the dashboard
Plan SaaS development costs around tenancy, permissions, billing and operations. Compare launch scopes and identify recurring cost drivers.
Mobile app development cost: platforms, devices and release work
Break down mobile app development costs across shared code, backend, device features, testing and store releases before comparing estimates.
Website development cost: how to compare scope and quotes
Plan website development costs around templates, content, integrations and launch checks. Compare quotes and calculate your own labour budget.