How to plan an MVP: a practical guide to your first software release

Begin with the uncertainty that makes a full investment difficult to justify. You may need to learn whether customers will complete a booking online, whether staff can manage jobs through one shared system or whether businesses will pay for a particular service. These are different questions. Each calls for a different scope and a different kind of evidence.

Write the intended user, problem and outcome in a short statement. For example: independent service businesses need a way to send quotations and track customer approval without searching through messages. The first release should show whether they can complete that workflow and whether the improvement is valuable enough to keep using. This is an illustrative example, not a claim about an existing aaliSoft client.

Agree what happens after the evidence is collected. The decision could be to improve the workflow, expand to another group of users, change the offer or stop development. An MVP becomes expensive when its purpose is simply to launch something and its success is judged afterwards using whichever numbers look encouraging.

A product can eventually serve several types of user without serving every group in its first release. Identify the person with the clearest problem and enough reason to try a new approach. Understand how that person handles the task today, what information is available and what would make switching worthwhile. An internal manager and an occasional customer may need very different experiences.

Map a complete journey with a clear beginning and end. For a quotation tool, that could run from creating a customer record to sending a quotation, receiving approval and handing the accepted work to the delivery team. A release that only creates attractive quotations may leave the real problem unresolved if approval and handover still disappear into separate conversations.

Include the ordinary exceptions needed to finish the task. A customer may request a revision, decline an offer or submit incomplete details. Staff may need to correct an entry. You do not need to automate every unusual situation immediately, but you do need to explain what happens when the normal path fails. Otherwise, users will quietly return to their previous tools.

List the assumptions behind the proposed product. Some concern demand: people experience the problem often enough to seek a solution. Others concern usability: they can understand and complete the task. Technical assumptions might include whether a required integration exposes the information the workflow needs. Test the uncertainty that could invalidate the project before polishing less consequential details.

The appropriate test depends on the question. Interviews and observation can reveal how work currently happens. A prototype can help you observe whether likely users understand a proposed interaction. A small technical investigation can check an integration. A pilot with an agreed manual process may reveal operational effort that a screen demonstration would miss. Record what each exercise can and cannot establish.

A positive reaction to a demonstration does not establish willingness to pay or sustained use. Ask people to attempt a realistic task and observe what they do. Keep the questions neutral and record difficulties as well as praise. Include people with different access needs where relevant. A prototype is useful evidence about a design, but it is not proof that the underlying service is secure, reliable or commercially viable.

Assess each proposed feature against the chosen workflow and the decision the release needs to support. Ask what would happen if the feature were absent. If the user could not finish the task, or the business could not operate it responsibly, it is likely to be essential. If it mainly improves convenience, presentation or a future business model, it may belong in a later release.

For the quotation example, creating and revising an offer, recording approval and showing the accepted version could be essential. Several dashboard styles, a referral scheme and a large template marketplace may be useful later. The boundary depends on the actual offer. A template marketplace would be central if discovering and buying templates were the product itself.

Keep a written list of deferred work with a reason for each choice. This prevents the same discussion from reopening every week and gives stakeholders confidence that their ideas have been considered. Review new requests by asking whether they replace something in the agreed scope, justify a revised estimate or wait until evidence from the first release is available.

A smaller scope still needs suitable controls. Decide what level of access protection, data handling, performance, accessibility and recovery is appropriate for the product. A pilot handling real customer records needs different preparation from a private clickable prototype using invented information. Make that distinction explicit before inviting anyone to use it.

Include the states people encounter when something goes wrong: an expired session, an unavailable service, an invalid upload or a failed submission. Explain whether an action completed and what the user should do next. Prevent avoidable duplicate entries where repetition could cause operational problems. A reassuring success message must reflect a successful action, rather than appear because a button was pressed.

Agree which checks are required before release and who accepts the result. Keep sensitive production information out of demonstrations and test environments unless appropriate controls and permission are in place. Testing with a few users can reveal important barriers, but it does not replace broader accessibility checks, security review or technical testing suited to the system.

Manual work can reduce initial development when the pilot volume is manageable and the process is clear. An employee might review a submitted application, approve a new account or prepare a specialist report. The user should receive a truthful explanation of the service and its expected timing. Do not present a manual review as an immediate automated result.

Name the person responsible for each manual step, specify the information they receive and explain how completion is recorded. Account for absence, rejected requests and overdue work. A temporary process becomes unreliable when it depends on someone remembering to check a personal inbox or privately tracking changes in a file nobody else can access.

Measure this operational effort during the pilot. If each request takes substantial staff time, include that cost when assessing the product. Set a review point for automation based on volume, risk and effort. Automating a poorly understood process too early can create rework, while leaving an overloaded manual process in place can damage the customer experience.

Describe completion through observable tasks. Instead of asking for a quotation management module, specify that an authorised employee can create a quotation, send it to the intended customer, revise it and identify the version that was accepted. Include access restrictions and important exceptions. The criteria should give the client and developer the same basis for deciding whether the work is complete.

Connect the criteria to a delivery plan with review points. Agree who supplies content, approves workflows, arranges access to external services and answers questions. Record dependencies that could delay a release even when development is progressing, such as an unconfirmed business rule or an integration account awaiting approval. A calendar date without those assumptions is difficult to assess.

The proposal should distinguish design, development, testing, deployment, pilot support and subsequent changes. Discuss what happens if testing invalidates an assumption. A planned review should allow the team to revise the approach without pretending that every discovery was predictable. Keep a record of scope decisions so that estimates remain understandable as the project develops.

Development is one part of the first-release budget. Allow for user research, design, content preparation, test data, integrations, hosting, monitoring, onboarding and support. If existing records must move into the product, include preparation and migration checks. For a public service, consider how users will discover it and what assistance they will need when they arrive.

Ask for a scope-based estimate with assumptions and exclusions. If the available budget is lower than the proposed release, reduce or change the workflow deliberately. Removing testing, backup preparation or essential access controls can leave the business with a product it cannot responsibly use. A narrower pilot or a simpler existing tool may be a better next step.

Estimate the ongoing operating cost at a plausible pilot volume. Subscription services, storage, messaging, payment processing and support effort may change as usage grows. Use current supplier prices when preparing the actual budget and keep uncertain items visible. There is no useful universal MVP price because the workflow, controls, integrations and delivery obligations differ between products.

Choose a pilot audience that reflects the users you need to learn about. A few colleagues who already know the design may overlook confusing language or missing instructions. Invite participants who carry out the relevant work and explain the boundaries of the pilot. Give them a clear route to report problems and agree how the team will respond during the trial.

Measure the outcome behind the product. A booking service should distinguish visits from completed bookings. An internal workflow should distinguish registered accounts from jobs successfully processed. Depending on the question, useful evidence might include task completion, repeated use, support requests, abandoned steps or time spent correcting records. Choose measures before launch and define how they will be recorded.

Combine numbers with observed examples and user conversations. A low completion rate might reflect confusing instructions, unavailable appointment times or people who never intended to book. Those causes require different changes. Collect only the information needed for a clear purpose and handle it appropriately. Analytics should help explain the workflow without becoming an excuse to collect unnecessary personal data.

Set a review after the pilot has had enough relevant use to answer the agreed questions. A date alone does not guarantee useful evidence. If too few suitable people tried the service, record that limitation rather than treating silence as success or failure. Review completed tasks, recurring difficulties, operating effort and feedback against the original objective.

Prioritise the next work by the barrier it removes. Improving an unclear approval step may help more than adding another dashboard. Some findings call for changes to pricing, training or the service itself rather than additional software. Keep a decision record explaining what the team learned, what will change and which assumptions remain unresolved.

A useful MVP creates a sound basis for further investment while delivering a coherent service to its initial users. Start with one meaningful problem, test the assumptions that matter and keep the first workflow complete. If you are planning a website, business application or SaaS product, aaliSoft can help define that release, prepare acceptance criteria and plan the development and support work around it.