A proof of concept gets built, quickly and often impressively. It convinces the people it needed to convince. Then the team that built it moves on, and someone else inherits the job of turning it into production software. When that someone calls us, the first conversation usually includes a sentence like "most of it is already built, so this should be quick."
It will not be quick. Taking an AI proof of concept to production usually means rewriting most of it, because the gap between the two is not a polish gap. It is a purpose gap. The PoC was built to win a decision, and production software is built to run unattended on real data. Budget for a rebuild with a head start, not for a finish.
Why a working AI proof of concept is not mostly done
A proof of concept (PoC) is a build made to answer one question: can this work? That is its whole job, and everything about it serves that question. The happy path is paved and the unhappy paths are stubbed. Credentials sit wherever was fastest. The data is a curated sample. Error handling is one try/catch around the demo flow. None of that is sloppy. It is correct engineering for an artifact whose purpose was to earn a decision.
Production answers a different question: can this work every day, unattended, on the worst input a real user will send, inside your security boundary, at a cost someone keeps approving? On July 29, 2024, Gartner predicted that 30% of generative AI projects would be abandoned after proof of concept by the end of 2025. It named poor data quality, inadequate risk controls, escalating costs, and unclear business value as the causes. A demo never has to face any of the four.
What gets rewritten between PoC and production
In our experience, half to four fifths of a typical AI PoC gets rewritten on the way to production. The rewrite concentrates in five places.
Input handling. The PoC saw clean data. Production sees the real distribution: malformed, enormous, and adversarial input. Model behavior on input unlike the sample is its own failure surface.
Evaluation and monitoring. The PoC was judged by eye. Production needs a written definition of acceptable output, a continuous measure of it, and an alarm when quality drifts. This layer is usually missing entirely at handoff, and it is the largest single build item. We describe what it contains in why AI agents stall in production.
Security, tenancy, and access. The demo ran as one trusted user. Production needs authentication, authorization, audit, and data boundaries. Retrofitting tenancy into code built without it touches nearly every file.
Cost shape. Nobody meters a demo. Token and compute spend under real load is a design constraint, and it often forces caching, routing between models, or batching.
Prompt and model brittleness. PoC prompts are tuned to the sample data and to the model version of the month they were written. Production needs versioned prompts and regression tests that run on every model update. It also needs a plan for the day the model goes away. Anthropic's model deprecation policy, for example, gives at least 60 days' notice before retirement, and after that date requests to the retired model fail.
Why a fixed price is the wrong contract for an inherited PoC
A fixed price on an inherited PoC prices a rewrite nobody has scoped. The buyer asks for one because most of the work looks done. A vendor who agrees is pricing code it did not write, against an evaluation standard that does not exist yet. Either the vendor pads the number and you overpay, or it underprices the work and you spend the engagement negotiating change orders. Both outcomes come from pretending the uncertainty is smaller than it is.
The shape that works is a capped engagement with an honest discovery phase at the front. Discovery produces a production architecture, a build plan, and a cost ceiling. The cap gives the budget owner a real number, and discovery earns that number instead of inventing it. The same logic applies to running an AI pilot that does not waste the budget.
The review to run before the build
The pre-build review has one deliverable: a written path to production. It records what the PoC actually does, checked against what people believe it does. It names the binding constraints: data access, evaluation, security, and cost. It states what gets kept, what gets rewritten, and in what order. It defines, in measurable terms, what "working" means once the system is live.
One caution from our own handoffs: do not frame this review as an audit of the PoC team. The PoC succeeded, which is why anyone is having this conversation. Teams that turn the handoff into a blame exercise lose the most valuable resource in the project, which is the builders' memory of the corners they cut and why.
Inheriting promising AI work and carrying it to production is a growing share of what we do, and it is what our AI implementation framework is built for. If you have a PoC that earned its next step, tell us about it, and we will help you find the real distance to production before a budget gets set against the wrong number.