The decision
These deliverables answer different questions. A prototype explores whether people understand an interaction. A proof of concept investigates whether a technical approach can work under stated conditions. An MVP delivers a limited but usable outcome to real users. None automatically proves the others.
A worked example
Suppose a business wants to read delivery notes and update stock. A prototype tests how staff correct a recognised quantity. A proof of concept measures extraction against a labelled sample set. An MVP connects intake, review and an authorised stock update, with recovery when an update fails.
Write a different success test for each deliverable
For a prototype, ask a participant to correct an extracted quantity without coaching and explain what they expect the next action to do. Observe misunderstandings rather than measuring how enthusiastically they praise the design. For a proof of concept, define the labelled documents, the fields being evaluated and the unacceptable error classes before running the experiment. For an MVP, follow a permitted user through the actual document-to-stock workflow, including the review queue and a failed update. These are three different acceptance tests. Keeping them separate prevents a success in one area from being used as a blanket claim of readiness.
Make shortcuts visible in the handover
A prototype may contain static values, a feasibility experiment may run from one developer's machine, and an MVP may rely on a manual exception process. These can be reasonable boundaries when they are explicit. Record the assumptions, the unimplemented behaviours, the test environment and the data permissions. Mark illustrative screens so they are not mistaken for a working customer product. If code is reused, review the parts that were unnecessary for the experiment but necessary for operation: authentication, configuration, error handling, observability, deployment and maintenance. Reuse should save supported work, not carry hidden liabilities into production.
Choose the next step from the result
If people cannot understand the correction screen, another technical extraction experiment will not solve the observed problem. If extraction fails on an essential document layout, more interface polish will not make the workflow reliable. If both work but users do not have the documents available at the right moment, investigate the operating process before expanding the product. Write a short decision after each test: what was learned, what remains unknown and what change will be tried next. This gives a founder a coherent path through uncertainty without claiming that every idea must pass through an identical sequence of deliverables or that every experiment deserves a launch.
Alternatives worth weighing
- Choose a prototype for uncertain usability, a technical experiment for uncertain feasibility and an MVP for uncertain adoption or workflow value. Sometimes two are needed, but each should have a separate question and completion criterion. Reusing experimental code is a decision, not an entitlement.
Where the plan breaks
Avoid showing a polished mock-up as evidence that data extraction works. Equally, a successful extraction script says little about permissions, deployment or support. Record shortcuts and test conditions so the next team does not inherit hidden assumptions.
Before you commission the work
What decision will this evidence change? Which inputs are representative? What would count as failure? Agree those points with your MVP development partner before selecting the deliverable or committing to a release date.