Estimate an MVP without inventing a price

Price the decision before the feature list

Start with the decision the MVP should support. It may need to show that a user understands one workflow, that a technical integration is feasible or that a small group returns to a useful action. Those questions require different evidence and therefore different work. A list of screens without a decision can grow while remaining impossible to accept. State the user, problem, smallest release, non-goals and what happens after the result is observed.

Separate a prototype, a private production pilot and a public product. A prototype may use temporary data and manual steps because it answers an interaction question. A production pilot needs identity, permissions, monitoring, recovery and support appropriate to real users. A public release may add store, legal, accessibility, analytics and operational work. Calling every stage an MVP hides the cost boundary and makes proposals difficult to compare.

Count interfaces, states and responsibilities

Each external system adds more than an API call. Estimate authentication, permissions, rate limits, error responses, retries, duplicate prevention, test access, provider review and ongoing change. Data import adds mapping, validation, correction, privacy and deletion. Mobile distribution adds signing, store records and review dependencies. Ask which integration facts are already verified and which remain assumptions that need a discovery task.

User states matter as much as screens. Include empty, loading, offline, expired, rejected, partial, unauthorised and recovery paths. Record who supplies content, owns accounts, reviews security, accepts design and answers provider questions. Work left to the client is still part of the schedule even when it is absent from the supplier invoice. A credible estimate names these dependencies instead of hiding them behind a single development number.

Choose the evidence and quality bar

Define acceptance at the level appropriate to the risk. A simple internal tool may need representative workflow tests and a manual recovery path. A consumer app may need device coverage, accessibility, privacy controls, store checks and support. A system that handles sensitive data or meaningful external actions needs stronger access, logging, review and incident preparation. These obligations change effort even when the visible interface looks small.

List the environments and evidence required: local checks, preview, staging, provider approval and production observation are different. Decide what must be automated, what can be reviewed manually and who signs off. Do not confuse a passing test with customer adoption or revenue. Product metrics require a separate measurement plan and time after release. Keeping that distinction prevents business promises from being priced as if engineering alone controlled them.

Estimate with ranges and change rules

Break the work into discovery, design, implementation, integration, verification, release and handover. For each package, write assumptions, dependencies, owner and acceptance evidence. Use a range where information is incomplete and identify the decision that would narrow it. A contingency should correspond to named uncertainties, not a hidden percentage added without explanation. Compare proposals by what they include and exclude, not by the total alone.

Agree how scope changes. A useful process records the new fact, effect on evidence, alternatives and decision owner before schedule or cost changes. Protect the smallest release by moving optional work to later decisions rather than quietly expanding every part. If a fixed budget is the hard constraint, reduce scope or evidence ambition explicitly. Do not preserve an impossible feature list by assuming unverified work will be free.

Include launch, maintenance and exit

The build cost is not the operating cost. Add hosting, provider plans, data, store accounts, monitoring, support, security updates, backups and incident ownership where they apply. Identify who reviews dependencies and platform changes after launch. A cheap first build can become expensive when no one owns recovery or the next release. A slightly smaller product with clear operations may be the better investment.

Require repository and provider ownership, deployment instructions, environment inventory, known limits and a practical handover. Decide whether the next step is internal hiring, retained support or a new scoped engagement. Revisit the estimate after discovery and after the first production evidence. The goal is not to predict the entire product. It is to make the next investment understandable, bounded and reversible.

Decision criteria

Use the same questions for every option before choosing.