A prototype can make an idea understandable. An MVP can test whether a particular group of people gets value from it. A production product can reliably deliver that value to real customers. These are not three boxes on a universal maturity ladder. They answer different questions, and choosing the wrong one can waste months of work.

The useful founder question is not “Are we ready to build the full app?” It is “What must we prove next, to whom, and with what evidence?” That decision determines scope and safeguards.

Three different questions, not three feature counts

Prototype: can people understand and use the idea?

A prototype might be a clickable design, a scripted demonstration or a disposable technical experiment. It helps you examine comprehension, workflow and feasibility before committing to a service. A polished prototype may have no operational process behind it. Do not confuse the appearance of a product with evidence that people will adopt one.

Google’s account of design sprints describes testing prototypes with real customers in a compressed research cycle. That is valuable evidence about the experience, but it is not automatically evidence of repeat use, willingness to pay or reliable delivery.

MVP: will a specific customer get enough value to return?

An MVP is a narrow real offer designed to learn from actual use. It might contain only one end-to-end workflow and a considerable amount of human work behind the scenes. Agile Alliance’s definition of an MVP puts learning about customers at its centre: observe what people actually do with the offer, rather than relying only on what they say they would do.

Minimum does not mean carelessly built. If the MVP accepts customer information, sends real communications or makes promises about delivery, it needs controls proportionate to those actions. Product scope can be small while operational responsibility is real.

Production: can you deliver the promise repeatedly?

Production is a commitment about service, not a magic feature threshold. Can the team support users, recover from errors, handle access appropriately, explain limitations and keep delivering when the founder is unavailable? An MVP may already be in production for a small pilot audience. Equally, a large feature-rich application may still be unfit for customer use.

Start with the riskiest assumption, not the longest backlog

Write down the decision you are trying to make. “We need an app” is not a testable decision. “Will operations managers use a shared request tracker instead of email for recurring approvals?” is closer. Now separate three uncertainties: whether the problem matters, whether the proposed workflow solves it, and whether you can deliver the service consistently.

• Problem evidence: can target users describe a recent instance, its consequences and their current workaround?
• Value evidence: do users complete the important task and choose to use the solution again without constant prompting?
• Delivery evidence: can the team meet its stated pilot promise with a support process and an honest understanding of the manual effort?

Do not combine these signals into one “validation score”. A user liking the interface says little about purchasing behaviour. A single successful task says little about recurring demand. And recurring demand does not mean the operation is ready to scale.

A hypothetical founder tests one customer workflow

Consider a hypothetical founder creating a tool for small facilities teams to request and approve routine maintenance visits. The initial concept includes dashboards, automated supplier matching, payments, notifications and reporting. But the founder’s immediate question is simpler: will a facilities manager use one shared request-and-approval workflow instead of coordinating it by email?

First, test the workflow without pretending it is a service

The founder shows a clickable prototype to relevant managers and asks them to work through a recent realistic request. The team watches where participants hesitate, what information they expect and whether the approval steps match their real responsibilities. The test is not a sales demonstration. The founder records observations and separates what people actually did from what they said they might do.

Then, run a deliberately narrow pilot

If the workflow appears useful, the founder offers a limited pilot: named participants at a small number of invited organisations can submit requests, nominate an approver and see a clear status. Supplier coordination happens manually by the founder’s team. There is no automated matching or payment feature. Participants are told exactly which steps are manual, expected response windows, who to contact and what the pilot does not cover.

The team avoids collecting unnecessary personal details, uses appropriate access restrictions and keeps an accountable route for correcting requests. If a failure could leave a site without essential maintenance, the pilot must not replace the existing urgent-response channel. These are boundaries of the offer, not features to defer until a later funding round.

Agree the evidence before looking at the results

Before inviting users, the founder writes a short decision record. The following are illustrative targets, not observed results or universal benchmarks:

• Hypothesis: invited managers with recurring requests will complete a request and approval without the founder guiding each screen.
• Activation criterion: at least six of eight invited managers complete one realistic request within the agreed pilot period.
• Repeat-use criterion: at least four return to submit a second genuine request, where another request naturally arises.
• Service boundary: no unresolved request is left without a named owner beyond the response window promised to pilot participants.
• Stop or revise: pause expansion if participants cannot complete the core workflow, if the manual workload is unsustainable, or if an important failure cannot be handled within the stated pilot boundaries.

These illustrative thresholds should reflect the opportunity and consequences of failure. A small sample can reveal serious workflow problems, but it cannot justify sweeping market-demand claims. Record who was eligible, who declined, which requests were genuine and why people stopped.

Manual work is acceptable; invisible manual work is not

Founders sometimes treat manual fulfilment as an embarrassment. In an early experiment, it can be the cheapest way to learn which steps deserve software. Y Combinator’s startup sequencing advice explicitly recognises manual work behind a stripped-down initial service.

But manual work must be visible in the economics and the customer promise. Count the time spent chasing approvals, correcting records, answering questions and resolving exceptions. Ask whether they teach you anything or conceal a broken process. Do not advertise instant automation while somebody is manually copying information between systems.

For the facilities example, a manually coordinated supplier is a reasonable pilot choice if customers understand the arrangement. A fake automated status, an unsupported guarantee or an undisclosed dependency on the founder being awake at all hours is not.

Use evidence to choose the next investment

At the end of the pilot, resist the urge to declare it a success because people were polite. Review actual completion, repeat use, exceptions, support time and interviews together. Atlassian’s MVP guidance frames early releases around gathering feedback and using it to guide subsequent development, rather than shipping a predetermined full feature set.

• If people cannot understand the workflow: revise the prototype and test the confusing step before building more infrastructure.
• If they understand it but do not use it: revisit the customer, urgency and proposition. Adding dashboards may not address the problem.
• If they use it but delivery is fragile: invest in stabilising the actual service, support ownership and the failure paths encountered.
• If they return and the operation holds: automate the most costly repeated manual step, then test whether that change preserves the experience.

Keep a simple evidence log: assumption, test, participant type, observed behaviour, exception, decision and next test. Include negative findings. Stopping can prevent an unproven build.

When should an MVP be treated as a production service?

As soon as real people depend on the service, the founder owes them clarity and proportionate reliability, even if the feature set is tiny. Define who can use it, what data it handles, what happens when it fails, how users obtain help and how the pilot can end without leaving them stranded. The exact safeguards depend on the product and the impact of a failure; a simple internal scheduling experiment is not equivalent to a safety-critical or regulated service.

This is why “MVP versus production-ready” is often the wrong argument. MVP describes the learning scope. Production readiness describes whether the delivery arrangement is fit for the promises being made. Both can be true at once.

For the technical work involved once you are preparing a real service, see our separate guide to taking an AI prototype into production.

Choose the next proof, then build only what supports it

Before approving another sprint, finish this sentence: “We will invest further if we observe ___ from ___ users under ___ conditions, without crossing ___ boundary.” If you cannot fill it in, another feature is unlikely to resolve the uncertainty.

Venturist helps founders review what they have built, identify the next useful proof and decide whether to refine the experience, stabilise a working product or prepare for launch. If you have an AI-built prototype or early MVP, start with a product review with Venturist and bring the customer promise, pilot evidence and outstanding questions—not just a feature wishlist.