What is a minimum viable product? A guide for UK startups

What does MVP mean in business?

MVP stands for minimum viable product. It is a usable first version designed to test a meaningful assumption with real customers. Minimum describes the scope, not the care taken with people's information or the reliability of the core task. Viable means the intended user can get the promised value, even if some work behind the scenes is manual.

For example, a hypothetical booking startup might first help one type of business receive requests and confirm availability. It does not need a marketplace, loyalty scheme and complex pricing engine to learn whether businesses will use that service. This is an illustration, not a CodeCue client case study or a promised route to growth.

The useful output is a decision: continue, change direction or stop. A release that attracts compliments but tells you nothing about repeat usage, willingness to pay or the difficulty of delivery has not resolved much uncertainty.

MVP vs prototype vs proof of concept

A prototype demonstrates an experience. It might be a clickable set of screens rather than working software. It can reveal confusing language or navigation, but it cannot establish that a production service works reliably. A proof of concept tests technical feasibility, such as whether an integration can retrieve the required records.

An MVP puts a limited offer in front of real users so you can observe its value. It may include manual work, but the service being offered must be honest about what it does. Choose the cheapest experiment that answers your current question: a prototype for usability, a proof of concept for technical uncertainty, or a small live product for actual behaviour.

Choose one assumption before choosing features

Write a sentence you could prove wrong: a particular customer group will use a particular service because their current alternative creates a particular problem. Then name the evidence that would support or challenge that claim. Avoid starting with a long feature wishlist and calling its cheapest version an MVP.

For a hypothetical business booking tool, the assumption might be that staff will manage requests through a shared queue rather than through scattered messages. Your experiment needs a way to receive requests, assign responsibility and confirm the outcome. A customised dashboard theme does not test that assumption.

• Customer: name one specific group you can actually reach.
• Problem: describe what goes wrong in their current process.
• Task: define the complete action the product must support.
• Evidence: agree what behaviour would justify another release.
• Review: decide who will assess the results and make the next decision.

What should be built, done manually or deferred?

Build the parts needed for the customer to complete the core task and for the team to deliver it safely. In the booking example, that could mean a request form, a shared record and a confirmation. If multiple businesses use the service, preventing one business from seeing another's records is foundational rather than an optional extra.

Keep low-volume internal work manual if it does not undermine the promise. A founder might initially approve each booking or prepare a report by hand. Explain any relevant limits to users and record the time this takes: an attractive service that depends on unpriced manual effort may not become a sustainable business.

Defer features that do not test the first assumption: extra integrations, elaborate analytics, referral schemes or additional customer groups. Maintain a visible later list so stakeholders understand that these ideas are postponed, not forgotten. Revisit them after observing the first release rather than committing to them all in advance.

How do you know whether an MVP worked?

Measure the journey from first contact to completed task, then look for return usage and a meaningful commitment. A sign-up is different from a completed booking; a completed booking is different from a customer choosing to use the service again. Track the distinction rather than presenting every registration as product validation.

Use interviews alongside product activity to understand why people stopped. Did they not need the service, fail to understand it, encounter an error or prefer their existing process? Those explanations lead to different decisions. A small early sample is a learning source, not a reliable forecast of the whole UK market.

Set your own review criteria based on the business model and the risk you are testing. There is no universal conversion rate or number of users that proves an MVP is successful. Record the initial criteria before launch so enthusiasm does not quietly replace the original question.

What should UK founders consider before launch?

If the release collects personal information, consider what you need, why you need it, who can access it and how long it will be retained. Data protection belongs in the early design, not in a policy added after launch. Sensitive data or a regulated activity may make a casually assembled experiment inappropriate; seek suitable specialist advice.

Agree ownership of code, domain names, hosting accounts and any paid services before commissioning development. Separate the cost of the first build from hosting, maintenance, support and later changes. Neither a small scope nor a low initial bill removes the need to plan who operates the product when customers depend on it.

Your next step: write a one-page MVP brief

Describe the customer, their problem, the single end-to-end task, what can be handled manually and the evidence you need. Add the integrations, data involved and the person responsible for reviewing results. This gives a development partner something more useful than a list of screens.

CodeCue's London-based software and SaaS services are relevant once you can explain that first task and its constraints. A discovery conversation should help separate a prototype from a live release and expose unknowns before quoting. No MVP scope, launch date or commercial outcome is guaranteed without reviewing the actual requirements.