Choose a clickable prototype when you need to test whether people understand, value and can navigate the workflow. Choose a production-ready MVP when you need evidence that real customers can complete that workflow repeatedly with real data, integrations, security, support and measurable outcomes. In many cases, prototype first and build the narrow MVP only after the key interaction risk is reduced.
This is a web design and AI automation decision as much as a software-delivery decision. A realistic interface can validate an idea, but it cannot prove production reliability or data governance.
The GOV.UK Service Manual recommends using prototypes to explore and test designs before committing to build, because teams can test multiple approaches at lower risk Source: GOV.UK.
Name the riskiest assumption
Write the decision the artefact must support. Are you uncertain that customers have the problem, understand the flow, trust the interaction, can complete the task, will pay, or can use the service under real operating conditions?
A prototype and MVP answer different questions. Building the more expensive artefact without naming the risk creates false progress.
Use the MVP development guide to frame desirability, usability, feasibility, viability and compliance assumptions.
Understand what a clickable prototype proves
A clickable prototype can demonstrate screen sequence, wording, navigation, information needs and interaction concepts. It is fast to change and safe to discard. It can support user research, stakeholder alignment and estimates.
It does not prove database integrity, concurrency, security, real integration behaviour, accessibility conformance, performance or supportability. Participants may also behave differently with fake data and no real consequence.
The website wireframe glossary explains one of the lower-fidelity artefacts that can precede a clickable prototype.
Understand what a production MVP proves
A production MVP is the smallest end-to-end service that delivers valuable outcome to a defined customer group under real conditions. It includes enough reliability, security, privacy, accessibility, monitoring, support and operational ownership to be used responsibly.
“Viable” does not mean feature-complete or beautiful. It means the customer can finish the promised workflow and the business can operate it without concealed manual chaos or unacceptable risk.
An MVP should produce evidence about activation, completion, repeat use, willingness to pay, support burden and unit economics.
Prefer a sequence when uncertainty is layered
Start with interviews, process observation and low-fidelity sketches where the problem is unclear. Use a clickable prototype to test the workflow and language. Build a technical spike for difficult integration or performance risk. Then create a narrow production MVP.
GOV.UK describes alpha as the stage for testing riskiest assumptions with prototypes that are only complex enough for learning and may be discarded Source: GOV.UK.
Do not carry disposable prototype code into production merely to meet a date. Preserve insights, not accidental architecture.
Define the one valuable workflow
Write a start trigger, user, desired outcome and completion evidence. Map every human and system step. Examples include submitting an accreditation evidence pack, approving a service quote or reconciling a document exception.
Remove adjacent features that are not required to complete, verify or support that outcome. Keep necessary exception handling.
Use the discovery phase checklist to identify must-have, manual bridge, later and explicitly excluded steps.
Set prototype research questions
Test whether representative users know where to start, understand terms, provide required information, recover from errors and know when the task is complete. Include people with different devices, language backgrounds and accessibility needs.
Observe behaviour rather than asking only whether participants like the design. Use realistic scenarios and neutral facilitation. Separate a problem in the concept from a problem in the prototype's fidelity.
Define what evidence would change the flow or stop the idea before sessions begin.
Set the MVP quality floor
List non-negotiable production conditions: authentication, authorisation, encryption, data retention, backups, audit logging, monitoring, availability, response time, accessibility, browser support and incident handling. Tailor them to risk.
Do not classify all non-functional requirements as later work. A workflow using customer records cannot be viable without appropriate security and recovery.
Keep the floor narrow and explicit. Enterprise-grade does not mean building every future scaling feature before the first user.
Decide how real the data must be
Prototype with synthetic or controlled data where possible. Avoid copying production personal information into design tools. Explain simulated behaviour to participants.
For the MVP, define authoritative records, validation, migration, deletion and reconciliation. Use the minimum data required. Test corrupt, missing and duplicate cases.
If an AI component is included, evaluate output quality, escalation, human oversight and vendor data handling separately from the interface.
Test integration risk independently
A clickable flow can hide the hardest work behind a button. Identify payment, CRM, identity, messaging, document, legacy and external API dependencies. Build technical proofs for the riskiest interfaces before promising the MVP date.
Test timeouts, rate limits, partial failure and recovery. Decide which manual bridge is acceptable for a limited pilot and disclose it honestly.
A manual operation can support learning, but it should not impersonate automation in cost or scalability claims.
Include the service operation
Define onboarding, support, incident escalation, refunds or corrections, account closure and communication. Name the people who will operate the pilot and how issues enter the backlog.
The valuable workflow includes what happens when the happy path fails. A user who cannot recover is not receiving a viable service.
Measure staff time and manual work. An apparently successful MVP can have unsustainable hidden operations.
Plan measurement before build
Define activation, workflow start, completion, time to value, error, abandonment, repeat use, support and paid conversion events. Add qualitative interviews and outcome verification.
Instrument the prototype only when it aids research; direct observation is often stronger. Instrument the MVP reliably and protect personal information.
Create an evidence dashboard that distinguishes invited, activated, completed, retained and paying users rather than celebrating registrations.
Set the decision gates
After prototype research, decide to proceed, change, test another concept or stop. Set minimum evidence such as repeated task completion and resolved comprehension barriers, not a stakeholder preference vote.
After the MVP, decide whether to expand, repair, pivot or close based on customer outcome, adoption, quality, operational cost and commercial evidence.
GOV.UK says alpha should leave a team able to decide whether tested ideas are worth taking into beta and whether the service can meet needs cost-effectively Source: GOV.UK.
Estimate total learning cost
Compare research, design, engineering, infrastructure, security, legal, support and opportunity cost. A prototype is cheaper but may leave operational risk unanswered. An MVP is more expensive and can be wasteful if the interaction concept remains unvalidated.
Model time to decision, not only time to artifact. Two weeks of prototype research can prevent months of production rework.
Include the cost of discarding code. Throwaway work is rational when it buys decisive evidence cheaply.
Prevent stakeholder expectation drift
Label prototypes visibly and explain simulated elements. Do not use a polished prototype to imply that production is nearly complete. Maintain separate backlogs and environments.
For the MVP, publish included workflow, exclusions, pilot conditions and known limits. Do not promise roadmap items as current capability.
Keep research findings, architecture decisions and acceptance criteria in the handoff from design to engineering.
My take: build the smallest truth
My take is that “smallest” should describe the scope, while “truth” describes the evidence. A prototype should truthfully expose how people understand the idea. An MVP should truthfully expose whether the business can deliver the outcome in production.
If your business needs a practical starting point, write the one decision you cannot make today. Choose the cheapest artefact that can produce credible evidence for it.
Frequently asked questions
Can a clickable prototype be sold to customers?
Use it for research or demonstrations with clear disclosure. Do not represent simulated behaviour as a working production service. Label it clearly and limit access to the intended research participants.
Must an MVP be scalable to millions of users?
No. It needs appropriate capacity and a credible growth path for the defined pilot, without unsafe shortcuts. Document expected load and the triggers for a capacity upgrade before launch.
Is manual work allowed behind an MVP?
Yes, when disclosed, measured and safe. Use it to learn, not to hide an uneconomic operating model. Measure the staff time so the team understands the real cost of delivery.
When should we skip the prototype?
When usability and concept evidence are already strong and the main uncertainty requires real operational use. Document why, and confirm that technical and operational risks have another credible test.
Choose the artefact that answers the real risk
If your business needs a clear path from concept to live value, get in touch for SaaS development and workflow automation.