MVP vs Full Product: What Should a UK Founder Build First?
Compare prototypes, concierge tests, MVPs and fuller products, then choose the smallest credible scope that resolves your UK startup’s riskiest assumption.
Muhammad YaseenFounder
25 Aug 202614 min read70
On this page
The Short Answer
Build the smallest credible product that can reduce your most important uncertainty.
That may be a clickable prototype, a manually delivered concierge service, a no-code workflow, a production MVP or a fuller product. The right choice depends on what the business still needs to learn, not on how few screens the team can place in a first-release backlog.
Choose an MVP when real use of a working product is necessary to test customer behaviour, operational delivery or continued demand.
Choose a fuller product when the first release must satisfy substantial privacy, security, integration, reliability or trust requirements before meaningful use is possible.
An MVP should be smaller than the eventual product. It should not be a low-quality version of it.
MVP Does Not Mean Every Feature Built Cheaply
A minimum viable product is a learning vehicle. It combines enough value and credibility for a defined user to complete a meaningful journey while limiting investment in assumptions that have not yet been proven.
Each word matters:
Minimum limits the scope to what is necessary for the decision.
Viable means the product can credibly deliver the promised outcome.
Product means a user can actually use it rather than merely hear a pitch.
Removing quality from essential areas does not make a release more useful for learning.
If customers abandon an application because authentication fails, the interface is inaccessible or they do not trust its handling of personal information, the team has not necessarily disproved the underlying need. It may only have tested an inadequate implementation.
The useful question is not:
Build with FlutterCraft
Define the smallest credible product
Turn your customer outcome, riskiest assumption and credibility requirements into a focused first-release scope and evidence plan.
Muhammad Yaseen is the Founder of FlutterCraft. He writes for founders and business leaders making high-stakes decisions about MVPs, digital investment, development partners, product validation, and sustainable growth.
Related articles
Continue with more FlutterCraft thinking for founders and product teams.
Learn how to scope MVP UX around the core task, user trust, accessibility and product learning while deliberately deferring polish that does not reduce launch risk.
What is the smallest credible way to test the assumption that could make this business fail?
Identify the Uncertainty Before Selecting the Build
Start by writing the decision the first release must support.
Examples include:
whether a defined customer group experiences the problem frequently enough;
whether customers will change an existing behaviour;
whether someone will make a meaningful commercial commitment;
whether a third-party integration can support the required journey;
whether the business can deliver the service operationally;
whether customers will trust the product with the requested information;
whether the economics remain credible when delivery is repeated.
GOV.UK’s discovery guidance is written for public services, but its core product discipline is useful beyond government: understand the problem, users, existing journey and constraints before committing to a solution.
The guidance also explains that stopping after discovery is not a failure when the evidence does not support proceeding. GOV.UK discovery guidance
Classify the uncertainty before discussing features.
Uncertainty
Question to answer
Useful early evidence
Customer problem
Does the problem occur, and is it important enough to change behaviour?
Interviews, observation, current workarounds and repeated problem signals
Demand
Will the target customer take a meaningful next step?
Qualified sign-ups, deposits, purchase intent with conditions or pilot commitments
Usability
Can the intended user complete the core journey?
Task-based prototype or product testing
Technical feasibility
Can a critical integration operate within its constraints?
Technical spike, proof of concept or limited integration test
Operational feasibility
Can the business deliver the promised outcome consistently?
Concierge pilot, service blueprint and measured manual delivery
Trust and compliance
Can the product meet the privacy, security and sector expectations required for use?
Risk assessment, specialist review and production controls
Commercial viability
Can the business acquire, serve and retain customers on credible terms?
Pricing tests, sales evidence, delivery cost and repeat-use data
Do not ask one build to answer every uncertainty simultaneously. Select the assumption most capable of invalidating the current plan.
Choose the Right Learning Vehicle
Experiment
An experiment tests a narrow assumption without pretending to be the product.
A landing page, pricing conversation, workflow simulation or manual test may be enough to explore demand. It must be honest. Do not imply that an unavailable product is already operational or collect commitments under misleading conditions.
Use an experiment when building software would add little evidence.
Clickable Prototype
A prototype tests comprehension, navigation, workflow and interface ideas. It is useful when the largest uncertainty is whether customers understand the proposition or can complete the intended journey.
GOV.UK recommends using alpha to test risky assumptions with prototypes that are only complex enough for the question, rather than treating prototype code as production code. GOV.UK alpha guidance
A prototype cannot prove production reliability, repeat usage or payment behaviour by itself.
Concierge Service
A concierge approach delivers the intended outcome manually behind a simple customer experience.
It can test:
whether the result is valuable;
which inputs are genuinely required;
where operational exceptions occur;
how much human work delivery needs;
which steps should eventually be automated.
Use it when the workflow remains uncertain and automation would hide learning behind engineering effort.
No-Code or Low-Code Pilot
A no-code workflow can connect forms, records, notifications and existing tools quickly. It may be useful for internal operations, controlled pilots and relatively simple data flows.
Before choosing it, check:
data ownership;
access control;
export options;
integration limits;
expected usage;
audit requirements;
the cost and feasibility of moving away.
A fast pilot can become an expensive dependency if the business treats it as an unlimited production platform.
Production MVP
A production MVP is appropriate when customers must use a real product for the business to learn.
It should include:
one complete customer outcome;
credible onboarding and authentication;
essential data and integration paths;
understandable loading, empty and error states;
proportionate accessibility, privacy and security;
analytics supporting the product decision;
operational support and recovery;
enough engineering quality to release and improve safely.
A production MVP is not necessarily temporary. Its architecture should allow learning without assuming the entire future roadmap.
A fuller first release supports more of the end-to-end service, operating model and required risk controls.
It may be appropriate when meaningful use requires:
several tightly connected user roles;
critical integrations that cannot be simulated;
reliable migration from an existing system;
regulated or high-risk information processing;
robust permissions and audit history;
high availability or incident response;
accessibility across a broad audience;
contractual service commitments;
mature customer support and administration.
“Fuller” does not mean building every roadmap idea. It means the credibility floor is higher because an incomplete service would not produce valid evidence or would expose customers and the business to unacceptable risk.
When an MVP Is Usually Appropriate
An MVP is normally suitable when:
a clearly defined user can receive value from one focused journey;
secondary workflows can be delivered manually;
integrations can be limited without invalidating the test;
the product can begin with a controlled customer group;
failure is reversible and does not create disproportionate harm;
the team can measure the intended outcome;
feedback can influence the next release;
the business accepts that the evidence may support stopping.
The product should still be credible.
For example, a B2B workflow tool might begin with one user role, one data source and one approval journey. It still needs dependable access control and recovery because customers cannot evaluate the workflow if they lose records or see another organisation’s information.
When You Need More Than a Thin MVP
Personal Information Is Central to the Product
The ICO states that data protection must be considered from the design stage and throughout a product’s lifecycle. It also requires organisations to limit personal-information use to what is necessary for the specified purpose. ICO data protection by design guidance
Privacy cannot be placed in a “later” backlog simply because the release is called an MVP.
The necessary controls depend on:
the information being collected;
why the business needs it;
who can access it;
how long it is retained;
the consequences if it is misused or exposed;
whether the processing presents a high risk to people.
High-risk processing may require a data protection impact assessment and specialist advice.
This does not always require a large product. It requires the right foundation.
Security Failure Would Cause Serious Harm
Authentication, authorisation, secure data handling, dependency management and incident planning are not optional polish.
The NCSC’s secure-development guidance recommends established development practices and secure-by-design measures throughout the software lifecycle. NCSC secure design and development guidance
A controlled pilot may reduce exposure, but it does not remove the need to understand threats or protect customers.
The Integration Is the Product
If the promised outcome depends on an accounting platform, payment provider, identity service, logistics network or legacy system, a disconnected prototype may test only the interface.
Test the riskiest integration early. That may mean building a technical proof before investing in a polished customer application.
The test should establish:
whether the required data is available;
whether permissions and commercial access are realistic;
whether performance supports the journey;
how failures and rate limits behave;
whether the integration can be supported after launch.
Operations Cannot Be Hidden
Marketplaces, managed services and products involving physical fulfilment may depend on people and processes outside the application.
A concierge pilot can reveal these operations. Before expanding, the business still needs evidence that fulfilment time, quality, exceptions and support demand remain manageable.
The application cannot compensate indefinitely for an operating model that does not work.
Trust Depends on Completeness
Customers may reasonably expect history, permissions, confirmation, recovery, support and transparent status before placing confidence in a product.
In these cases, removing a trust feature can invalidate the test. A customer’s refusal to use an unsafe or unclear release is not evidence that the underlying need is absent.
A Seven-Step Scope-Selection Framework
1. Define the Customer Outcome
Write one sentence:
For [specific user], the first release enables [meaningful outcome] in [defined situation].
Avoid describing screens or technology.
A customer outcome might be:
For an independent clinic manager, the first release confirms appointment reminders without requiring staff to update two systems.
“Build an appointment dashboard” is a proposed solution, not an outcome.
2. Define the Decision
State what the business will decide after the release:
proceed;
change the audience;
change the proposition;
revise the delivery model;
invest in automation;
expand the pilot;
stop.
Without a decision, an MVP can become a vague first phase that expands indefinitely.
3. Name the Riskiest Assumption
Write the assumption in a falsifiable form.
For example:
We believe independent clinics will replace their current reminder process when setup can be completed without changing their booking system.
This exposes several testable conditions.
“Clinics like our idea” does not.
4. Select the Cheapest Credible Test
Choose the least expensive method that can produce trustworthy evidence.
If you need to learn whether...
Start with...
Move to software when...
Customers understand the workflow
Clickable prototype and task testing
Real data or repeat behaviour becomes necessary
Customers value the delivered result
Concierge pilot
Manual delivery limits learning or repeatability
A critical integration is feasible
Technical proof of concept
The integration can support a complete journey
Customers will commit commercially
Structured sales or pilot test
Product use is required to validate retention
Users can complete the journey independently
Focused production MVP
The journey and credibility requirements are understood
The whole operating model works
Controlled end-to-end pilot
Demand and delivery constraints are sufficiently evidenced
5. Set the Credibility Floor
List what must work for the result to be valid:
privacy and security;
accessibility;
data accuracy;
response time;
customer support;
integration reliability;
recovery from failure;
clear commercial terms.
These are not automatically features for later. They define whether customers can participate in the test meaningfully.
The credibility floor should reflect the risk. A private prototype using fictional data does not need the same controls as a public product processing sensitive personal information.
6. Define Evidence Before Building
Choose a small number of measures connected to the decision.
GOV.UK’s performance guidance recommends defining success and measurement early, then combining performance information with continued user research. The exact public-service metrics are not automatically suitable for a private startup, but the underlying discipline remains useful. GOV.UK performance guidance
Possible startup measures include:
successful completion of the core outcome;
time or effort required from the customer;
repeat use within the relevant customer cycle;
movement from trial to a meaningful commitment;
operational effort per completed outcome;
failure and support rates;
evidence explaining why customers continue or stop.
Avoid selecting measures because they are easy to collect. Select them because they will affect the decision.
Do not collect personal information merely because it might become useful later. Measurement should remain proportionate to its stated purpose.
7. Set Stop, Change and Expand Gates
Agree the decision rules before launch:
Stop when the problem, demand or delivery model is not supported.
Change when the need is real but the audience, journey or proposition is wrong.
Expand when the outcome, demand and operating model have sufficient evidence.
Investigate when the evidence remains inconclusive.
This turns an MVP into a managed investment rather than a smaller commitment to the complete roadmap.
Three Hypothetical Scope Decisions
These examples are illustrative, not client stories.
Example 1: A New Consumer Marketplace
The largest uncertainty may be whether sufficient buyers and suppliers can be matched in one location.
A full marketplace platform could hide that uncertainty beneath months of engineering. A manual matching service with clear customer communication may test the operating model first.
Build marketplace automation when repeated matching activity reveals which parts create the greatest delay, cost or customer frustration.
Example 2: A B2B Workflow Product
The customer problem may be well understood, but the product depends on access to a third-party business system.
The first investment should test that integration’s permissions, data quality, rate limits and failure behaviour. A polished standalone interface cannot prove that the intended workflow is feasible.
Once the integration is credible, a focused MVP can test independent use and continued value.
Example 3: A High-Trust Customer Product
A product processing sensitive or consequential information may need stronger identity, permissions, audit history, recovery and operational support from its first real release.
The product can still have narrow functional scope. However, the trust and safety foundation must be complete enough for meaningful use.
In this case, “minimum” applies to the number of outcomes, not to the protection around them.
Evidence Required Before Expanding
More features are justified when they remove a demonstrated constraint.
Look for evidence across five areas:
Customer outcome: users can complete the meaningful journey.
Behaviour: users return or continue at a frequency appropriate to the product.
Commercial commitment: the target customer accepts credible terms.
Operations: the business can deliver and support the outcome repeatedly.
Technical quality: reliability, security and integration performance support controlled growth.
A feature request is not automatically evidence of priority.
Connect each request to:
the observed customer problem;
the customer group affected;
the outcome it may improve;
the strength of existing evidence;
its implementation and operating cost;
what will be delayed if it is selected.
Continue learning after launch. GOV.UK’s user-research guidance recommends research throughout discovery, alpha, beta and live operation rather than treating initial discovery as final. GOV.UK user-needs guidance
Common MVP Scope Mistakes
Starting With a Feature List
A feature list explains what might be built. It does not explain what the business needs to learn.
Start with the customer outcome and decision. Add only the capabilities needed to support them.
Copying an Established Competitor
An established product contains features accumulated across customers, operating constraints and years of decisions. Copying its visible interface does not reproduce its evidence or business model.
Treating Manual Work as Failure
Manual delivery can be appropriate when it produces learning about exceptions, customer expectations and operational cost.
The problem arises when manual work is hidden, unmeasured or presented as scalable when it is not.
Ignoring the Post-Launch Operation
A first release still needs ownership.
Before launch, decide:
who monitors failures;
who answers customers;
who can correct data;
how releases are approved;
how an incident is handled;
how evidence reaches the roadmap.
Expanding Before the Result Is Clear
Adding features during an inconclusive test makes the next result harder to interpret.
When evidence is weak, improve the test before increasing the product.
What Should You Build First?
Choose:
an experiment when behaviour can be tested without a product;
a prototype when usability or comprehension remains uncertain;
a concierge service when the outcome and operations need validation;
a no-code pilot when a controlled workflow can provide credible evidence;
a production MVP when real product use is required;
a fuller product when trust, integration, regulation or operations establish a higher minimum.
The best first release is not the one with the shortest feature list. It is the smallest credible investment that helps the business make a better decision.
Muhammad YaseenFounder
