Most AI projects stop at the PoC (Proof of Concept) stage. The demo runs. It just doesn't reach production. This isn't a technology problem — it's a PoC-design problem: the conditions to reach production weren't built into the PoC from the start. Here are the three conditions we've observed make the difference in the field.
Condition 1: Bake production requirements into the PoC design
Many PoCs are built to check "does this run." But the PoCs that don't reach production share something in common: the three production requirements — accuracy, operational load, and cost — were never considered at design time.
Take a corporate document RAG (Retrieval-Augmented Generation) PoC. "It worked on 200 sample documents" doesn't decide anything for production. Production needs to handle tens or hundreds of thousands of documents. Decision-makers want the accuracy threshold (e.g., "85%+ correct answer rate"), update operation model (who ingests new documents, when), access permissions (per-team access control), and annual cost estimates (API costs + operations effort) as decision inputs.
Reason backward from the production metrics you want to reach, at PoC design time. That's the first condition.
Condition 2: The decision-maker is seeing investment-decision metrics
PoCs are often started by ground-level curiosity, and finished with ground-level evaluation. But the production decision is made by executives or division heads. What they're looking at isn't demo polish — it's return on investment.
Even if the ground floor says "it was useful," the approver can't sign off without a model of "how much does production cost, and how much does it return." At the PoC stage, estimated running cost (API costs, operations payroll, maintenance fees), projected savings (time saved, revenue lift, cost reduction), and payback period (typically 12–24 months is acceptable) need to be on the table.
If those numbers are sloppy, the approver thinks "the PoC was fun, but I don't have the courage to put this into production."
Condition 3: The operations team is already preparing during the PoC
Who uses this once it's in production? Who operates it? Who keeps the data fresh? Engagements where these answers aren't decided during the PoC stall — even after a "yes" to production.
AI systems aren't built once; they're maintained to keep improving. Decide an internal owner (the product-owner role) early, and run a dry run of the operations flow during the PoC. That's the third condition.
In our engagements, when a PoC starts we also agree on "who does what in the first 3 months after production launch." We run the technical PoC and the organizational PoC in parallel. Empirically, PoCs that skip this step reach production at roughly a 30% rate, while PoCs that build it in reach 70–80%.
Wrap-up: treat the PoC as a transition design, not a test
PoCs don't fail to reach production because they're poorly built. They fail because we frame PoC too narrowly as "technical validation." Bake production requirements, investment-decision logic, and operating-team design into the PoC at design time. That's the condition.
PlusDivide designs PoCs as transition-to-production projects. We don't just ship something that runs — we carry it to where it ships.
FAQ
Frequently Asked Questions
What's a realistic timeline and budget for an AI PoC?
Field experience suggests 4–8 weeks and ¥500K–¥3M. What matters more than time and budget is whether production requirements (accuracy, operations, cost) are designed into the PoC from day one. Short PoCs with production requirements baked in convert to production at a higher rate than long PoCs that only validate technology.
What's the single most common reason PoCs don't reach production?
Not technology — the three production requirements (accuracy, operational load, cost) were never considered at PoC design time. Demos run, but production data volume, operational flow, and annual cost are invisible, so decision-makers can't act on the investment decision.
What does an executive need to see to approve production?
Three numbers: projected operating cost, projected savings or returns, and payback period. Approval flows when these are clear. They don't when the demo was fun but the numbers are sloppy.
Who should own an AI system internally?
Not IT, not engineers — a business-side leader with operational responsibility (division head, sales head, finance manager). AI isn't built once; it's maintained to keep improving. The person who owns the business outcome and has decision-making authority is the right product-owner role.
What should I verify when ordering a PoC from a development partner?
Three things: (1) Are production requirements (accuracy lines, operational design, cost estimates) part of the PoC deliverables? (2) Is a transition plan to production included? (3) Will the stack stay a black box if you switch partners later? Vendors selling "technical validation only" rarely deliver PoCs that reach production.