MVP Development: Define the First Useful Release
On this page
An MVP is an experiment designed to test a consequential assumption about a product. In the Lean Startup methodology, its purpose is to begin a cycle of building, measuring and learning. A prototype or a manually delivered service may be enough for an early question; a complete software release is not always the first investment required.
This guide focuses on the next situation: real users need working software to test a business workflow. That release still needs the data, permissions, exceptions and quality checks required for its intended use. A customer portal, an internal operations system and a marketplace have different users and launch risks. Define the question the release must answer before estimating its cost or timing.
Choose one workflow and one decision
Start with the situation that makes someone open the product. For example, a distribution team needs to see which orders are at risk of missing dispatch, inspect the reason and assign the next action. That is more useful than a feature list headed “orders dashboard”.
Write down:
- Who starts the workflow, and what triggers it?
- Which records do they need to trust?
- What decision or action should the system support?
- Which exception can stop the normal path?
- How will the team recognise that the first release works?
State a hypothesis that could be contradicted by the result. For our distribution example: giving dispatchers an exception queue with a named owner will reduce unresolved shortages at the dispatch cutoff, without increasing incorrect stock allocations. This separates the intended benefit from the condition that must not deteriorate. It is an illustrative hypothesis, not a measured client result.
Map the complete path, including exceptions
For the order example, the first path might be: receive an order, check available stock, flag a shortage, show the responsible team and record the decision. It may also need permissions, a retained customer record and an exchange with an existing warehouse system.
An acceptance scenario should describe what happens when stock is insufficient or a source update fails. The team can then review a working release against business situations instead of judging only whether each screen is present.
Defer purchasing automation, advanced forecasts or a customer portal if they are not needed for the chosen workflow. Agree the boundary with the business owner and delivery team.
Decide what to build, connect and defer
Not every needed capability should be custom-built. Review the tools and data your business already has. A current identity provider, accounting platform or reporting environment may remain in place if it meets the requirements and exposes a workable connection.
Classify each item in plain language:
- Needed for the first usable path: the workflow, roles, records, exceptions and checks without which the release cannot be used safely.
- Needed to operate it: data transfer, integration, monitoring, documentation and onboarding for the people using it.
- A candidate for a later release: valuable work that is not required for the first agreed outcome.
- Still unknown: data quality, third-party access, rules or technical constraints that require investigation before they can be estimated reliably.
User onboarding and data transfer belong in the first scope when the team cannot start work without them.
Plan existing data before implementation
If users already work in a CRM, ERP or spreadsheets, the first release needs a clear data plan. Decide which history moves, which system owns each record during transition and whether selected data must stay synchronised.
For migrated data, specify field mapping, duplicate handling, sample transfers and validation against the source. For an ongoing connection, specify update direction, frequency, error handling and reconciliation. These are different tasks and should appear separately in the estimate.
The legacy software modernisation page shows an explanatory customer-record transition. The Solution Studio includes a separate interactive import and sync demo with sample data.
Build reporting around an action
A report belongs in the first release when a user needs its answer to operate the workflow. For the order example, “open orders past planned dispatch date” needs a definition, a report date, source records and a way to inspect the blocker. It also needs the right access for each role.
You can build that view in the new system, integrate an existing BI tool or synchronise data to a reporting environment. Agree the source, filters, refresh needs and validation method before choosing a chart. The custom ERP page includes a sample order-exception report.
Review a working release in stages
During design, review the main steps of the workflow. During development, check the agreed scenarios in working software. Complete data migration and onboarding before launch. The proposal should name the reviewers, deliverables and responsibilities, and explain how scope changes affect cost and timing.
Data cleanup, third-party access, availability requirements and business review time determine the schedule. Estimate these dependencies alongside the development work, with named owners for unresolved questions.
Understand the investment
At Horizon Dynamics, full custom software project budgets start at USD 50,000. We work with an hourly team or a fixed price for a defined module, depending on the engagement. An assessment can be scoped separately where it is useful. The actual estimate depends on the agreed workflows, roles, data, integrations, quality requirements and rollout.
Pricing & Process explains the two payment models and the work behind an estimate. In Solution Studio, you can select demo modules and see an example budget for the set. The ranges help you explore scope before a proposal prices your project.
Before comparing proposals, check whether each includes analysis, design, testing, data transition and deployment. Our paid support is required after launch and is priced separately from the illustrative build cost. Ask which warranty fixes are covered and how support, client-paid hosting, licences, paid APIs and future development appear in the proposal.
Review the first release before approving expansion
Use a normal task, an exception, a restricted record and a failed external handoff as acceptance examples. Name the business reviewer and agree the go/no-go evidence, data reconciliation and fallback. Our sample delivery brief connects these checks to scope and cost.
Learn from the first release
Before launch, define the observation period, eligible orders, baseline and review decision. For the example, count orders still blocked by a shortage at the same dispatch cutoff and divide by all orders due for dispatch in that period. Keep both counts: a change from 4 of 20 to 4 of 40 is a lower rate, but it has not reduced the number of blocked orders. Record cancellations and any exclusions consistently.
Track incorrect allocations, unresolved integration failures and manual interventions alongside that outcome. Compare similar order types, team coverage and workload, and record changes in staffing or supplier performance. A before-and-after pilot can guide the next iteration, but cannot by itself isolate the software's effect from those changes. A small sample should be reported as counts and observations, not as a precise forecast of future savings.
Review where users get stuck and why records are corrected. Agree whether the evidence supports expanding, revising or stopping the proposed workflow. Usage alone does not establish value, and adoption of an internal tool does not demonstrate external customers' willingness to pay.
If you are planning a first release, share the workflow, current systems and decisions you need to support. You can discuss the project without a finished specification.
