From proof of concept to production: what needs to change

A demonstration and an operation answer different questions.

A proof of concept asks whether an approach can work. It might test extraction from a small document set, demonstrate a workflow, or check whether an approved source provides the necessary information.

Production asks a broader question: can the people responsible for this process use and operate the system repeatedly, including when inputs are missing or something fails?

A successful demonstration is useful evidence. It is not, by itself, evidence that the system is ready for unrestricted use. Its findings should identify what is known, what remains uncertain, and what the next stage must establish.

Make the input assumptions explicit.

Demonstrations often use a convenient sample. Day-to-day work introduces duplicate requests, older document formats, incomplete records, access changes, and unusual cases that were absent from the initial test.

Build a representative evaluation set and describe its limits. Define what happens when the input falls outside those limits. A reviewer should be able to see the original source and understand why a case was flagged.

For AI-assisted work, evaluate the resulting task, not only whether an answer reads well. A plausible explanation can still contain an incorrect field or lead to the wrong action.

Agree what the system may do.

Decide which people can access the application, which sources it can read, and which actions it can take. An action that changes a record, sends a message, or triggers a payment needs a clear authorization boundary.

Separate suggestions from approved decisions. Define when a person must review an action and make that review practical: useful context, source information, and a clear way to accept, correct, or reject the proposal.

Give failures an owner and a recovery path.

A missing feed should not silently look like a quiet day. A retry should not create a second order. A provider interruption should not leave the team guessing whether the task completed.

The exact controls depend on the workflow, but the operating questions are consistent. Who sees a failure? What information helps them resolve it? Can the work be retried safely? Is there a manual path while the system is unavailable?

• Monitoring tied to the workflow’s important outcomes.
• Clear handling of duplicate events, partial completion, and retries.
• Operational instructions and escalation responsibilities.
• A rollout and recovery approach matched to the business risk.

Roll out in a scope you can assess.

A controlled pilot gives a defined group a usable workflow and a way to report problems. Agree acceptance criteria, compare against the baseline, and make changes before expanding the scope.

Production work can then strengthen an existing solution: deployment, monitoring, error handling, documentation, and handoff. Major new functionality is a different scope from preparing an existing system for use.

The final handoff should name the operational owner, the support responsibilities, and what happens next. Readiness is a set of demonstrated behaviors and agreed responsibilities, not a label applied to the demonstration.