Nearly every company we speak to has already built the demo. Someone technical spent a weekend, wired a model to a document store, and showed something genuinely impressive in a meeting. Then it sat there for eight months.
The instinct is to blame the model — it hallucinated, it was too slow, it was too expensive. Occasionally that is true. Far more often the demo failed to become a system for reasons that have nothing to do with the model at all.
A demo answers a question. A system owns a job.
A demo is judged by whether the output was impressive once. A system is judged by what happens on the bad day: the malformed input, the ambiguous request, the case where being confidently wrong costs real money. Demos have no failure path because nobody asked them to have one.
The work of productionising AI is mostly the work of designing failure. What happens when confidence is low? Who is notified? What is the fallback, and is it worse than doing nothing? Is there a record of what the system decided and why?
Three things demos never have
- An evaluation set. If you cannot measure whether a change made things better, you cannot change anything safely. Most teams have no test set for their AI feature — something they would never accept in the rest of their codebase.
- A boundary. A demo will happily answer anything. A system needs an explicit scope, and a graceful, honest response when a request falls outside it.
- An owner. Prompts drift, models are deprecated, source documents go stale. Something that changes underneath you needs a person responsible for it.
The cost curve is not where you think
Teams optimise inference cost long before it matters and ignore the cost that actually bites: the human time spent verifying output nobody quite trusts. A system that is 95% accurate but gives no signal about which 5% is wrong forces a human to check 100% of it. You have not automated the task. You have added a review step.
Calibrated uncertainty is worth more than a few points of raw accuracy. Knowing when to escalate is a feature.
What we do differently
We start from the exception, not the happy path. Before building anything we ask what the process does today when something goes wrong, who handles it, and what that person needs to see. That conversation usually reveals that the valuable automation is somewhere adjacent to where the demo pointed.
Then we build the evaluation harness before the feature. It is unglamorous and it is the reason the thing is still running a year later.