MVP development cost depends on the smallest release that can answer a useful business question with an appropriate level of reliability. A short feature list is not enough: a single booking, approval or payment task may involve permissions, connected systems and operational recovery.
Use an estimate to decide which learning or business outcome to fund first. Distinguish a disposable experiment from software that real users will depend on. They can share an interface while requiring very different data handling, testing and support.
Decide whether you need a prototype or an operational release
A prototype might test whether someone understands a journey without connecting production systems. An operational minimum viable product, or MVP, must complete an agreed task under the conditions in which it will be used. Label the intended use before suppliers estimate it.
The GOV.UK alpha guidance describes using prototypes to explore ideas and risky assumptions. That public-service approach is useful context, not a prescribed timetable or a substitute for deciding whether your own first release must operate with real customers.
Define one outcome and a measurable learning question
Suppose a fictional maintenance business wants customers to request visits without repeated email exchanges. Its first question is whether a structured request gives dispatchers enough information to assign a visit. It does not yet need automated route optimisation, a customer mobile app or a marketplace.
Write the outcome, user, starting state and successful end state. For this example: an existing customer submits a request; a dispatcher reviews it; the customer receives a confirmed or declined response. State which decisions remain manual. A useful MVP can deliberately keep an uncertain process under human control.
Scope the workflow before listing screens
| Part of the example | First-release assumption | What could increase effort |
|---|---|---|
| Customer identity | Invited existing customers | Public registration and complex organisation access |
| Request | One request type with required fields | Attachments, branching forms and multiple products |
| Assignment | Dispatcher chooses an available team | Live capacity optimisation and external calendars |
| Notifications | One channel with visible delivery status | Multiple channels and customer-specific preferences |
| Reporting | Request queue and simple export | Custom dashboards and financial reconciliation |
Keep constraints with each assumption. An attachment may sound small but introduce file limits, access rules, retention questions and recovery cases. Estimate the business behaviour rather than assuming a component name represents a complete implementation.
Break development cost into inspectable work
Ask for effort against problem definition, interface design, application work, integrations, data preparation, assurance and release. Include review time from the business and access to representative test data. Person-days express effort; they do not show when a customer or external supplier will respond.
For the maintenance example, list concrete acceptance checks: a customer cannot see another customer's requests; a dispatcher cannot confirm an already declined request accidentally; and a failed notification is visible without losing the request. These checks make testing estimable and help prevent misleadingly cheap comparisons.
Use a transparent cost calculation
A simple model is the sum of role-specific effort multiplied by agreed rates, plus named external expenses. Keep the rate basis, currency and included services visible. Do not assume the same daily rate or day length applies to every supplier.
As an invented calculation, allocate 3 person-days to discovery, 4 to design, 12 to application development, 4 to a verified integration, 5 to testing and 2 to release preparation. The total is 30 person-days. At a purely illustrative blended rate of £650 per day, that is £19,500 before separate expenses and applicable tax.
Those numbers are not a market range, a ZakCodeX quote or a reliable estimate for your project. Their value is that the assumptions can be challenged. If the external system lacks a usable test environment, the 4-day integration allowance has no evidential basis until that uncertainty is investigated.
Compare scope options without hiding trade-offs
Create three options for the same business question. An experiment might use a clickable prototype and manual follow-up. A limited operational release might support invited customers and manual dispatch. A broader release might add public accounts and automatic availability checking.
For each option, show what the team can learn, which users it serves and which responsibilities remain manual. Do not represent an experiment as a cheaper equivalent to a production service. If a later option adds another 10 person-days at the illustrative £650 rate, its added arithmetic is £6,500; the actual change still needs a real estimate.
Keep uncertainty and dependency work visible
Give every material unknown an owner and a way to resolve it. Examples include whether the scheduling API supports provisional holds, how customer records will be matched and who approves notification wording. Ask for the cost of that investigation separately from any unverified implementation allowance.
Use confidence ranges tied to those assumptions rather than adding an unexplained percentage to the total. A risk allowance should have a purpose and a rule for use. Agree who can approve an option, remove scope or change the estimate as evidence arrives.
Include the cost of running the first release
List hosting, external services, monitoring, backup and recovery work, dependency updates and user support. Name the person responsible for checking failures and for deciding what gets built next. A working pilot still needs someone able to respond when its only integration is unavailable.
Measure use of the intended workflow and review the learning question after an agreed observation period. More features are not automatically the next step. Evidence may support changing the process, extending the release or stopping further development.
Prepare an MVP estimation brief
Bring one workflow, its acceptance examples, user and data boundaries, known dependencies and deferred features to an MVP development discussion. Ask for a proposal that explains scope and uncertainty as clearly as the headline amount.
The general software development cost guide covers wider budgeting considerations. Keep this first-release worksheet alongside it, so a broad application estimate does not replace a specific decision about what to validate and operate first.
