--- title: "Prototype, proof of concept or MVP: choose the evidence you need — Orvun Labs" description: "These deliverables answer different questions. A prototype explores whether people understand an interaction." canonical: "https://orvunlabs.com/en/journal/prototype-poc-or-mvp" language: "en" last_modified: "2026-09-13" --- # Prototype, proof of concept or MVP: choose the evidence you need These deliverables answer different questions. A prototype explores whether people understand an interaction. ![Prototype, proof of concept or MVP: choose the evidence you need](https://orvunlabs.com/images/blog/mvp.svg) - Published: 2026-09-13T09:00:00.000Z - [MVP & validation](https://orvunlabs.com/en/journal/topic/mvp.md) ## 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. ## MVP development A first product with a clear reason to exist. - [Discuss this service](https://orvunlabs.com/en/services/mvp-development.md) ## Related reading - [Writing product requirements without a technical background](https://orvunlabs.com/en/journal/product-requirements-for-founders.md) - [No-code, low-code or custom development for a first product?](https://orvunlabs.com/en/journal/no-code-low-code-or-custom.md) ## Let's make something useful. A first product, a difficult workflow or software that needs a fresh start. Tell us where you are. - [Tell us about your project](https://orvunlabs.com/en/contact) ## Structured data ```json { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://orvunlabs.com/#organization", "name": "Orvun Labs", "url": "https://orvunlabs.com", "logo": "https://orvunlabs.com/orvunlabs-icon-512.png", "description": "Custom software, SaaS products and AI-powered tools — designed around your business.", "knowsAbout": [ "Custom software", "SaaS product development", "AI integration" ] }, { "@type": "WebSite", "@id": "https://orvunlabs.com/#website", "name": "Orvun Labs", "url": "https://orvunlabs.com", "inLanguage": [ "en", "es", "de", "fr", "pt", "ja", "hi", "ar", "id", "tr", "pl" ], "publisher": { "@id": "https://orvunlabs.com/#organization" } }, { "@type": "WebPage", "@id": "https://orvunlabs.com/en/journal/prototype-poc-or-mvp#webpage", "url": "https://orvunlabs.com/en/journal/prototype-poc-or-mvp", "name": "Prototype, proof of concept or MVP: choose the evidence you need", "description": "These deliverables answer different questions. A prototype explores whether people understand an interaction.", "inLanguage": "en", "isPartOf": { "@id": "https://orvunlabs.com/#website" }, "about": { "@id": "https://orvunlabs.com/#organization" }, "breadcrumb": { "@id": "https://orvunlabs.com/en/journal/prototype-poc-or-mvp#breadcrumb" } }, { "@type": "BreadcrumbList", "@id": "https://orvunlabs.com/en/journal/prototype-poc-or-mvp#breadcrumb", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Orvun Labs", "item": "https://orvunlabs.com/en" }, { "@type": "ListItem", "position": 2, "name": "Prototype, proof of concept or MVP: choose the evidence you need", "item": "https://orvunlabs.com/en/journal/prototype-poc-or-mvp" } ] }, { "@type": "BlogPosting", "headline": "Prototype, proof of concept or MVP: choose the evidence you need", "description": "These deliverables answer different questions. A prototype explores whether people understand an interaction.", "datePublished": "2026-09-13T09:00:00.000Z", "dateModified": "2026-09-13T09:00:00.000Z", "inLanguage": "en", "author": { "@id": "https://orvunlabs.com/#organization" }, "publisher": { "@id": "https://orvunlabs.com/#organization" }, "image": [ "https://orvunlabs.com/images/blog/mvp.svg" ], "mainEntityOfPage": { "@id": "https://orvunlabs.com/en/journal/prototype-poc-or-mvp#webpage" } } ] } ```