How to Decide Between a Prototype and a Full Build

A prototype and a production build are not cheaper and more expensive versions of the same deliverable. They answer different questions. A prototype reduces uncertainty; a full build creates a system the business can rely on with real users, real data and ongoing support.

The right choice depends on what is still unknown. If the business problem, workflow and operating model are clear, building a disposable prototype may add little value. If the central assumption is untested, moving directly to production can turn uncertainty into expensive rework.

Define the decision the work must support

Before asking for an estimate, state what must be learned or delivered. A prototype is justified when a decision depends on evidence that documents and meetings cannot provide efficiently. Examples include whether users understand a new workflow, whether a difficult integration is technically feasible or whether a product concept solves a meaningful problem.

A full build is appropriate when the required outcome is operational: staff must use the system, customers must rely on it, transactions must be recorded and the business must support it after launch.

Use a prototype when the uncertainty is specific

A useful prototype has a narrow question and a defined result. It may test one core workflow, one risky integration or one user group. “Build something so we can see it” is not a sufficient objective.

Strong prototype questions include:

• Can staff complete the proposed approval process without extra offline work?
• Can the external system provide the required data at the necessary point in the workflow?
• Do customers understand the account-opening steps without assisted support?
• Can a complex record be represented clearly enough for a decision-maker to review it?
• Which of two process designs produces fewer mistakes?

Agree the evidence before work starts: observed completion, error rates in a controlled test, integration results, user feedback or a documented technical finding. The prototype is complete when that question has been answered, not when it resembles a finished product.

Start with a full build when the operating need is already clear

A full build is usually the better starting point when:

• the current process and its exceptions are understood;
• the business has already validated the need;
• the main workflows, roles and data sources are known;
• the system must operate with real customer or business data;
• there is a fixed operational dependency, such as replacing an existing tool;
• the uncertainty concerns delivery effort rather than whether the capability is needed.

Discovery and design are still required. Choosing a full build does not mean skipping requirements. It means the output of discovery is a production delivery plan rather than a temporary experiment.

Do not confuse a prototype, proof of concept and MVP

These labels are often used loosely, so define the intended outcome rather than relying on the name.

• Prototype: tests how a concept, process or interface may work.
• Proof of concept: tests whether a difficult technical approach is feasible.
• Minimum viable product: a deliberately limited product that real users can use and the business can operate.

An MVP is still a production system. “Minimum” reduces scope, not the need for appropriate access control, support, data handling and recovery.

Decide whether prototype code will be reused

There are two valid approaches. A throwaway prototype is built for learning and is not expected to become production code. An evolutionary prototype is designed as the first controlled part of the final system. Problems arise when a quick experiment is later treated as a production foundation without revisiting the shortcuts made for speed.

Before commissioning the work, record:

• whether the code is expected to be reused;
• which production standards are deliberately omitted;
• who owns the code, design files, research and findings;
• what must be rebuilt before real use;
• how the decision to continue, change direction or stop will be made.

Limit real data and operational dependency

A prototype should not quietly become a live system because users find it convenient. If real data is necessary for the test, define who can access it, how long it is kept and how it will be removed or transferred afterwards. A prototype that begins processing real customer work may create an unplanned support obligation and a difficult migration.

Make the boundary visible. Use a separate environment, test accounts and a clear notice that the system is not the production record unless the project has deliberately moved into a controlled pilot.

Set a time box and a decision gate

A prototype without an end condition can become an indefinite pre-project. Agree a short list of questions, the test method, the participants, the budget boundary and the decision date. At the review, choose one of four outcomes:

• proceed to a production build;
• revise the concept and run a further targeted test;
• adopt an existing product or simpler process instead;
• stop because the evidence does not support further investment.

Stopping after a useful negative result is not failure. It is one of the reasons to prototype.

Acceptance criteria for a prototype

A prototype should not be accepted against production criteria. Accept it against the agreed learning objective and deliverables. For example:

• Five representatives from the target user group complete the core workflow using the scripted scenario.
• The proposed integration returns the required fields for the agreed sample records, and its limitations are documented.
• The supplier provides the code, design files, test findings and a written list of production gaps.
• The final review records the recommendation, evidence and unresolved questions.

Questions to put to a supplier

• Which specific uncertainty will this prototype reduce?
• What will it deliberately not include?
• How will we know whether the result supports proceeding?
• Is the code disposable, reusable or undecided?
• What would need to change before any real users or data could depend on it?
• What assets and findings will be handed over at the end?
• How will the estimate for a full build be revised after the prototype?

Practical next step

Write the single most expensive uncertainty in one sentence. If a focused experiment can answer it, define a prototype around that question. If the uncertainty is already low and the business needs an operational capability, invest the effort in production requirements, acceptance criteria and a staged full build instead.