Direct answer: An MVP budget starts with one user outcome and the smallest reliable workflow that can test it. The main cost drivers are workflow complexity, integrations, data migration, security obligations, design depth and the amount of evidence needed before release.
Start with the decision the MVP must support
An MVP is useful when it resolves a specific product decision: will people complete a task, will an operator adopt the workflow, or will a customer pay for the result? Write that decision before listing features. Define the intended user, the moment they need the product and the evidence that would change the roadmap. A vague goal such as “launch a platform” creates scope without a test. A stronger goal might be to learn whether dispatchers can complete one recurring scheduling task with fewer manual handoffs.
Map the full journey, then cut a vertical slice
Sketch the journey from sign-in or intake to a completed outcome. Include errors, approvals and support, not just the happy path. Then choose one vertical slice that works end to end for a limited group. A slice can have a narrow feature set and still need dependable data handling and a usable interface. The UK Government Service Manual discovery guidance emphasizes understanding the problem, users and constraints before committing to a solution. That discipline applies to commercial MVPs as well: discovery should remove uncertainty before the team prices a large build.
Price complexity instead of counting screens
Two products with six screens can have radically different effort. A read-only dashboard over a clean API differs from a regulated workflow that creates records, manages permissions and reconciles third-party data. Estimate by capability and uncertainty: identity, core logic, data model, integration, content, analytics, accessibility, testing, operations and support. Distinguish a known implementation task from a question that needs a prototype. Unknowns should appear as explicit discovery tasks with decision points, not as false precision in a single fixed estimate.
Treat integrations and data as first-class scope
Ask whether the MVP needs live data from another system, how reliable that system is, who owns errors and whether historical records must be migrated. An integration may require mapping, retries, monitoring and a support process. If a spreadsheet import is adequate for the first test, it may be a responsible temporary choice; if accuracy or timeliness is critical, the integration needs production-grade treatment. Make that trade-off visible to the buyer and operators.
Budget for the minimum safe release
The smallest useful product is not necessarily the smallest amount of code. Protect credentials, validate inputs, back up important records and provide a way to detect failures. Set an accessibility baseline for the target users. Nielsen Norman Group’s discovery guidance explains the role of discovery in reducing product uncertainty; pair that with technical risk review so the team does not postpone basic reliability until after a pilot.
Use a staged budget and acceptance gates
Create a range for discovery, a range for the first vertical slice and a separate allowance for learning after launch. Tie each stage to deliverables: a validated journey and risk register; a working slice with agreed acceptance cases; then observed usage and prioritized changes. State what is excluded. If the scope expands, revisit the decision the MVP was meant to test. This makes cost control a product-management practice rather than a last-minute feature cut.
Plan the next conversation
Bring the workflow, target user, current workaround and key systems to a scoping session. Our product discovery and MVP service can turn these into a delivery plan; our software product development article explains how an MVP fits into a broader product path.
Frequently asked questions
How many features belong in an MVP?
Only the features needed to complete and measure one valuable journey. Count decisions and dependencies, not screens or backlog tickets.
Can we set an exact MVP price before discovery?
A useful range is possible when assumptions are explicit. An exact commitment is weaker when critical integrations, data quality or compliance needs are still unknown.
What should we leave for a later release?
Leave features that do not affect the first decision, while keeping security, data integrity and support needs required for the pilot.