How much does an MVP cost, and how long does it take?

Define the decision before defining the MVP

The useful first question is not how many features fit into an MVP. The useful question is which uncertain belief must become sufficiently credible before the organisation invests further. That belief may concern the user problem, willingness to adopt, operational feasibility, technical integration, commercial model, or ability to deliver safely.

Write the decision, current evidence, riskiest assumptions, intended participants, observable behaviour, success threshold, and stop condition. This prevents a large feature backlog from being relabelled as a minimum product without explaining what the release is meant to prove.

• Decision: what will the evidence allow the team to approve, change, or stop?
• Assumption: what must be true for the product to work as intended?
• Method: what is the smallest responsible test of that assumption?
• Threshold: what result would justify the next phase?
• Constraint: what must remain protected while the test runs?

Separate discovery, prototype, alpha, and live software

GOV.UK's Service Manual says discovery is for understanding the problem before committing to build, and that teams should not start building the service during discovery. Its alpha guidance recommends prototypes that are only complex enough to test the riskiest assumptions and warns that alpha code may be discarded. Those distinctions apply beyond government even though the exact process and duration will differ by organisation.[1][2]

A clickable prototype can test comprehension without accounts, a backend, or production security. A technical proof can test one integration without a complete interface. A controlled pilot can test real operations with a restricted audience. Public software needs additional reliability, accessibility, privacy, support, monitoring, and release work. An estimate must say which of these artefacts it includes.[3][4]

Estimate cost and time from the risk profile

MVP cost and duration are shaped by research access, number of user roles and journeys, design depth, data sensitivity, new backend services, third-party integrations, migration, identity and permissions, payments, offline behaviour, platform coverage, accessibility, assurance, stakeholder availability, and release obligations. The riskiest unknown may matter more than the visible feature count.

Create an assumption log alongside the estimate. For each uncertain item, record the current belief, evidence, impact if false, owner, planned test, and date for a decision. Price a discovery activity when an unknown cannot be estimated responsibly; do not conceal it inside an arbitrary contingency.

• Use ranges only when their assumptions and confidence are visible
• Separate third-party charges and internal client effort from supplier fees
• Show which dependencies can move the target release date
• Re-estimate after evidence changes scope or removes uncertainty

Build an evidence ladder instead of one oversized release

A practical sequence moves from cheaper evidence to more expensive evidence. First validate that the problem is real and important for a defined audience. Then test whether people understand and can use a proposed journey. Next prove critical technology and operations under controlled conditions. Only then expand reliability, coverage, and distribution for a production release.

Each stage should end with a documented decision: proceed, revise, repeat, or stop. GOV.UK's discovery guidance explicitly notes that stopping can save time and money when research shows that moving forward is not worthwhile. That outcome is valuable because it prevents unsupported confidence from consuming the larger build budget.[1]

• Problem evidence: interviews, observation, existing data, and service analysis
• Proposition evidence: content, journey, and prototype testing
• Feasibility evidence: integration, data, security, and operational proofs
• Behaviour evidence: a controlled pilot with representative users
• Scale evidence: reliability, support, economics, and repeatable acquisition

Ask for a milestone plan with explicit exit criteria

A credible proposal describes the team, phase objectives, research access, artefacts, working-software boundary, client responsibilities, dependencies, review cadence, acceptance criteria, release environment, ownership, and support. It should show when the estimate will be revisited and which decisions can reduce or expand scope.

A fixed budget can still support evidence-led delivery when the team fixes the investment and flexes the solution. Prioritise the assumption to test, protect the essential quality and safety constraints, and trade lower-value features before compressing assurance. The goal is dependable learning, not maximum output per sprint.