How to build an MVP from idea to real users

Write the problem in one sentence#

Name the person, the situation and the outcome they cannot achieve easily today. “Independent tutors lose bookings while arranging lesson times” is a more useful brief than “an education platform”. Record the current workaround and why someone would change it. This sentence becomes the test for every feature request.

Find evidence of existing behaviour#

Talk to people who actually face the problem. Ask about the last time it happened, what they tried and what it cost them. GOV.UK’s user-research guidance starts with understanding users and their needs. Use a manual service, prototype or landing page to test the riskiest assumption before committing to production software. Our validation guide explains how to set a decision threshold.

Define one complete user journey#

For a tutoring product, the first journey might be finding a suitable tutor, requesting a time and receiving a confirmed booking. Map both the visible screens and the work behind them. Someone must handle a rejected request, cancellation or unavailable tutor. A narrow journey still needs a believable ending.

Test the prototype#

Give representative users a realistic task without explaining where to click. Watch where they hesitate, misunderstand the offer or expect information that is missing. Fix the sequence before polishing every screen. A prototype can test understanding; it cannot establish that payments, permissions or integrations work in production.

Agree scope and acceptance criteria#

Write what the first release includes, what it excludes and how each part will be accepted. Replace “booking works” with observable behaviour: a user selects an available time, receives confirmation and can see the booking later. Name the launch audience, supported devices, administrator tasks and unresolved dependencies.

Choose the team and technical approach#

Choose a delivery model around the skills and ownership you need. Ask the team to demonstrate the hardest integration early. Prefer tools the team can maintain and hand over. Create the repository, hosting and service accounts under the business so access does not depend on one supplier.

Build in working slices#

Review a complete piece of the journey regularly, using realistic data. A working request-to-confirmation flow tells you more than a collection of finished screens. Keep a visible list of decisions, risks and deferred work. When new scope appears, agree which existing item moves out or how the budget and date change.

Instrument the outcome#

Define the event that represents value: a completed booking, a useful report or a successful order. Track the steps leading to it and the failures that prevent it. Collect only the information needed for those decisions. Set up error monitoring and make sure somebody is responsible for responding.

Release to a manageable first cohort#

Check permissions, recovery flows, accessibility, data handling and the main failure paths before inviting users. Verify that the team can deploy a fix and restore service if a release fails. Start with an audience you can support directly, with a clear way to report problems. Public availability and operational readiness are different milestones.

Decide what the evidence changes#

Review actual completion, repeated use and support conversations against the original hypothesis. Separate confusing execution from weak demand: people may want the outcome but struggle with your flow. Choose the next change deliberately. Add a feature only when evidence shows why it matters more than fixing the existing journey.

A first-cohort plan you can actually run#

Consider an illustrative service that helps a small set of tutors confirm lessons. The first release does not need a national directory, automatic pricing or a recommendation engine. It needs a learner to request a suitable lesson, a tutor to accept it and both people to know whether it will happen. Staff need a way to resolve a cancellation.

Do not use the number of accounts as the sole result. Record requests that reached confirmation, those that failed and why. Keep manual interventions visible: a useful concierge step can help the pilot, but it changes the economics and should be part of the next decision.

Make the launch gate observable#

Before inviting the cohort, agree who can approve the release and where the evidence lives. The owner should be able to find the current build, repeat the core task and see the results of access, payment and recovery checks that apply to the product. A slide saying “QA complete” is not the same as a record of what was checked.

• The core journey works for each role in a representative test environment.
• An interrupted or duplicate action leaves an understandable state.
• The team can diagnose a controlled failure and contact the right responder.
• The release can be recovered, and the operator knows the limits.
• Users know what the pilot includes and how to get help.

After release, keep one prioritised list with the problem, evidence, owner and expected benefit of each change. Resolve a broken existing outcome before assuming that another feature will improve adoption. Our willingness-to-pay guide helps distinguish use from a viable commercial offer.

Put this guide to work#

Frequently asked questions#

Sources and methodology#

This guide combines editorial analysis with the linked primary sources. Decision frameworks, worksheets and worked examples are our own; examples are illustrative unless explicitly identified as supplier claims or published research. We have not conducted original interviews, comparative supplier testing or a controlled experiment for this article.

1. GOV.UK Service Manual: learning user needs ↗

   Primary reference for the platform or practice discussed. Editorial examples and decision frameworks are our own.

   Accessed 16 October 2026
2. ICO: data protection by design and by default ↗

   Primary reference for the platform or practice discussed. Editorial examples and decision frameworks are our own.

   Accessed 16 October 2026
3. NCSC secure development guidance ↗

   Primary reference for the platform or practice discussed. Editorial examples and decision frameworks are our own.

   Accessed 16 October 2026

Source check: 16 October 2026. Platform documentation can change. Published as part of our editorial collection.

Expanded 16 October 2026 with practical decision material, downloads and topic-specific answers. Supplier and platform claims are identified by their linked sources.