Business POC: isolating the production prerequisites

The POC works, and still nothing ships

The scene is common. A team builds a proof of concept in a few weeks, the demo convinces everyone, leadership gives its agreement in principle. Then nothing. Six months later the tool still runs on the machine of whoever built it, on last year's data export, and nobody can say what is missing to put it in the hands of the teams.

This blockage is almost never technical in the narrow sense. The model works, the code runs. What is missing are the operating conditions: durable access to data, permissions, hosting, someone who maintains it, a written decision. We call these the production prerequisites, and the good news is that they can be identified during the POC, not after.

This article describes how to isolate those prerequisites from the start, family by family, so that a POC ends in a clear decision rather than in waiting.

What a POC proves, and what it does not

A business POC answers one precise question: is the expected result achievable on your data, at a quality the business accepts. Done well, it proves feasibility, reveals the real difficulty of the problem and shows what the tool would look like.

It proves nothing about the rest. It does not say whether data will be available every day, whether IT will accept the integration, whether processing will hold real volumes, whether cost per run stays bearable at scale, or who fixes an incident on a Tuesday morning. Confusing the two is the mistake that manufactures stalled projects.

Hence a simple rule: a POC has two deliverables, the result obtained and the list of prerequisites for production. The second matters as much as the first.

Write the exit criterion before starting

Before the first line of code, one sentence must be written and approved by whoever will decide: on what condition does this POC trigger a production project, and on what condition does it stop. For example, that information extracted from a document is accurate often enough for review to become a quick check rather than full retyping, on a representative sample chosen in advance.

Without that criterion, the POC is judged on the impression the demo left. With it, the decision rests on a measurement, and no becomes possible. A POC that stops cleanly, with a documented reason, costs far less than a project that drags for a year.

The criterion also describes the sample: how many cases, chosen how, including the hard ones and not only the cleanest. That is what prevents the POC demonstrated on five perfect documents.

The prerequisites to isolate during the POC

These are the families we review during a POC. Each is handled by a question asked early, often to someone outside the project team, and by an answer written into the report.

Data

• Durable access. A POC often runs on a one-off export. In production you need renewable access: a database, an interface, a file drop fed automatically. Who opens it, in what timeframe, with what authentication.
• Freshness. How current the data must be for the tool to be useful: live, within the hour, the next morning.
• Quality and edge cases. What the data really contains beyond the sample: empty fields, duplicates, legacy formats, documents scanned crooked.
• Real volume. Expected rows, documents and users, with peaks. The POC runs on one case, production runs on the flow.
• Usage rights. What the company is allowed to do with this data, especially when it comes from customers or partners.

Access and identity

• Who signs in and how. Existing company account, directory, two-factor authentication.
• Who sees what. Roles and scopes: one branch does not see another's files, one profile reads without editing.
• Joiners and leavers. How access is created and, above all, removed when someone changes role.

Integration with existing systems

• Points of contact. Which systems the tool must read or feed: ERP, CRM, business software, mail.
• The people. Who, in IT or at the vendor, opens those accesses, and in what timeframe. This is often the longest prerequisite, so the first to start.
• Environments. Is there a test environment, or must validation happen on real data, with the precautions that implies.
• Release windows. Freeze periods, financial closes, peak season when nothing moves.

Security and compliance

• The nature of the data. Personal data, sensitive data, trade secrets. This drives hosting, retention periods and the records to keep.
• Hosting and subcontractors. Where the application and the model run, who the providers are, what the contract says about reuse of data. Our article on hosting an AI project in France presents the options.
• Regulatory duties. Processing records, impact assessment where required, informing people, and the transparency duties described in our article on the AI Act for smaller companies.
• Logging. What the tool records for each run, so a decision can be explained later.

Reliability and operations

• Expected service level. What happens if the tool is unavailable for an hour, for a day. Often the answer is "we do it the old way", and that simplifies everything else.
• Monitoring. Who is alerted when a run fails, and through which channel.
• Backups and recovery. What is backed up, how often, and how it is restored.
• Support. Who a blocked user contacts, with what response time.

Cost and performance

• Cost per run. On a POC the model bill is trivial. At scale it becomes a line item. Measure it during the POC, then multiply by real volume. Our article on the cost of an AI agent in production details the items.
• Acceptable response time. An answer awaited on screen and an overnight batch are not designed the same way.
• Ceilings. What happens when consumption exceeds the plan: alert, queue, stop.

Output quality, where AI is involved

• The evaluation set. A set of cases with expected answers, built during the POC and kept. It is what will show that a model update broke nothing.
• The acceptance threshold. The level of accuracy above which the business agrees to rely on the tool.
• The place of the human. What a person approves before it has an effect, and what goes through on its own. Our responsible AI memo sets out the principles we apply.
• Out-of-scope behaviour. What the tool does when it does not know: it says so and hands over, rather than producing a plausible answer.

Ownership and what comes next

• A business owner. A named person who arbitrates and answers everyday questions.
• Training. On the real tool, with the team's data, not on a slide deck.
• Maintenance. Who fixes and who evolves it, with what access to code and hosting. Ownership of code and data is decided before production, not during a disagreement.
• Usage measurement. How you will know, in three months, that the tool is actually used.

The five most common traps

• The POC on sample data. It proves the technique works, not that your case works. Use your real data as early as possible, with the legal framework that goes with it.
• The POC running on a laptop. As long as nothing is hosted, no operating prerequisite has been met, so none has been handled.
• The POC never measured. Without a criterion written in advance, the decision becomes a matter of opinion, and opinion moves at every meeting.
• The prototype promoted to production by accident. A tool used daily with no backup, no permissions, no monitoring. The riskiest situation, because nobody decided it.
• Access requested too late. Opening access to an internal system often takes longer than the development itself. It is the first request to send, not the last.

A POC is not a sales demo

The confusion is common, because both end in a presentation. A demo aims to convince: it shows the best case, on chosen data, with a polished story. A POC aims to find out: it goes looking for the cases that hurt, it measures, and it accepts ending in a no.

The difference shows in what gets presented. In a POC, the most interesting part is not the demo that works, it is the cases that failed and what they reveal: an unexpected document format, a business rule nobody had put into words, a piece of data missing from the system. Those failures have value, because they are exactly what would have derailed the project six months later.

A successful POC can therefore end in a stop. What matters is not that the answer is yes, but that the answer is grounded and that the decision belongs to whoever commits the money.

Three questions before going to production

At decision time, three questions are enough to tell whether the prerequisites are genuinely handled or merely listed.

• If the tool goes down tomorrow morning, what does the team do? A clear answer, even "we go back to the spreadsheet for the day", proves the subject was examined. Hesitation shows operations were not considered.
• Who opens the accesses, and when? A name and a date. Without both, the production schedule is an estimate that will not hold.
• How will we know in three months that it worked? A measurement chosen before launch, comparable with a reading taken before. Without it, the tool will be judged on the mood of the moment.

What a useful POC report contains

At the end of a POC, the document handed over runs to a few pages and always contains the same elements: the question asked, the exit criterion written at the start, the measurement obtained on the sample, the list of prerequisites by family with an owner and a timeframe for each, an estimate of the remaining work, and a clear recommendation: go to production, adjust the scope, or stop.

That document has another virtue: it can be read by leadership who were not in the room. It is often what unlocks the decision, more than the demo itself.

How we work

Our engineers work at the client's site during the POC, alongside users, which means prerequisites are met in context rather than guessed. Access requests go out in the first week. The evaluation set is built with the business, not beside it. The POC is hosted, however modestly, so that the operating question arises immediately.

What follows depends on the result. The AI agent method and full application method pages describe what happens after a green light, and our article on deploying an AI agent in your company details the real steps, from scoping to debrief. The engagement page places the prototype among the five maturity stages.

To find out whether your subject deserves a POC, and which one, our AI diagnostic asks the right questions in a few minutes.

Frequently asked questions

How long should a business POC last?

Long enough to measure the exit criterion on a representative sample, and no longer. The duration is set during scoping, with a decision date. A POC with no end date becomes a project with no decision.

Should the POC run on real data?

Yes as soon as the legal framework allows, because real data carries the edge cases that make the project hard. Failing that, on a real anonymised sample, with a check on full data planned before production.

Which prerequisite blocks projects most often?

Opening access to internal systems. It depends on teams outside the project and often takes longer than the development. It is the first request to send.

Can a successful POC go to production as it is?

Rarely. It was built to answer a question, not to carry load, permissions and recovery. Some of the code is kept, the rest is rebuilt with the operating prerequisites in place.

What if the POC misses its exit criterion?

Stop it or reduce the scope, and document it. A reasoned no is a useful result: it avoids a project that would cost without delivering, and it often points to the subject that deserves the next POC.