There is a handoff happening all over the industry right now. A proof of concept gets built, often quickly, often impressively. It convinces the people it needed to convince. Then the team that built it moves on, and someone inherits the job of turning it into production software. That someone calls a firm like ours, and the first conversation usually contains a sentence like "most of it is already built, so this should be quick."
It will not be quick, and the reason is worth understanding before you budget, because the gap between PoC and production is not a polish gap. It is a purpose gap.
The PoC did its job. Its job is over.
A proof of concept is built to answer one question: can this work? Everything about how it is built serves that question. The happy path is paved; the unhappy paths are stubbed. Credentials are wherever was fastest. The data is a curated sample. Error handling is a try/catch around the demo flow. None of this is sloppiness. It is correct engineering for the artifact's actual purpose, which was to earn a decision.
Production software answers a different question: can this work every day, unattended, on the worst input a real user will ever send, inside your security boundary, at a cost someone will keep approving? Different question, different artifact.
In practice, expect half to four fifths of a typical AI PoC to be rewritten on the way to production. That number surprises people, so it is worth itemizing where it comes from:
- Input handling. The PoC saw clean data. Production sees the real distribution, including the malformed, the enormous, and the adversarial. For AI systems this is doubly true, because model behavior on out-of-distribution input is itself a failure surface.
- Evaluation and monitoring. The PoC was judged by eyeball. Production needs a definition of acceptable output, a way to measure it continuously, and an alarm for when quality drifts. This usually does not exist at all in the handoff and is the largest single build item.
- Security, tenancy, and access. The demo ran as one trusted user. Production has authentication, authorization, audit, and data boundaries, and retrofitting tenancy into something built without it touches nearly everything.
- Cost shape. Nobody meters a demo. Production token and compute spend under real load is a design constraint, and it frequently forces architectural changes: caching, routing between models, batching.
- Prompt and model brittleness. PoC prompts are tuned to the sample data and the model version of the month it was built. Production needs versioned prompts, regression tests against model updates, and a plan for the day the provider deprecates the endpoint.
Why fixed-fee is the wrong contract shape
Here is the commercial trap. The inheriting organization, believing most of the work is done, asks for a fixed price. A vendor who agrees is pricing a rewrite they have not scoped, on a codebase they did not write, against an evaluation standard that does not exist yet. Either they pad the number defensively, and you overpay, or they underprice it, and you spend the engagement negotiating change orders with a partner losing money on you. Both outcomes are bad, and both are caused by pretending the uncertainty is smaller than it is.
The shape that works is a capped engagement with an honest discovery phase at the front: a bounded review that produces a production architecture, a build plan, and a ceiling on cost. The cap gives the budget owner a real number. The discovery phase earns it, instead of inventing it.
The review that should happen before the build
Whether you run it with us or internally, the pre-build review has one deliverable: a written path to production. What the PoC actually does, verified against what people believe it does. What the binding constraints are: data access, evaluation, security, cost. What gets kept, what gets rewritten, in what order. And what "working" will mean, in measurable terms, once it is live.
One caution from experience: do not let this review be framed as an audit of the PoC team. The PoC succeeded; that is why anyone is having this conversation. Teams that turn the handoff into a blame exercise lose access to the single most valuable resource in the project, which is the builders' knowledge of the corners they cut and why.
The pattern of inheriting promising AI work and carrying it to production is becoming a meaningful share of what we do, and it is exactly what our AI implementation framework is designed for. If you have a PoC that earned its next step, tell us about it, and we can help you find the real distance to production before you commit a budget to the wrong number.