Most AI features die between the demo and the third week of production. The demo runs clean. The team is impressed. The feature ships. Then the support inbox starts filling with screenshots of weird answers, the bill triples, and someone notices the assistant has been recommending a competitor’s product for ten days because nobody was watching.
The model didn’t get worse. The demo never proved the thing the team thought it proved.
What a demo actually validates
A demo proves the model, given a specific input on a specific day with a specific prompt, returned a specific output. That’s it. It doesn’t prove the model returns that output reliably. It doesn’t prove the model handles inputs the demo didn’t show. It doesn’t prove the API will be up. It doesn’t prove the cost at volume. It doesn’t prove anyone will notice when the model is wrong.
None of those things matter in the room. All of them matter the first month after launch.
The pattern shows up in a lot of AI projects we audit. The demo was real. The integration was wired up correctly. What was missing was the engineering scaffolding around the model, the part that makes the difference between a feature that works on a good day and a feature that survives the first real user who doesn’t know what they’re supposed to type.
The four things production breaks on
The model is sometimes wrong. Modern LLMs are confident regardless of accuracy. They hallucinate facts, misread instructions, invent tool arguments, and occasionally produce text the brand should never have shipped. The question for a production feature isn’t whether this happens. It’s how often, how visible the failures are, and what happens when one slips through.
The API is sometimes down. Every model provider has incidents. Rate limits get hit. Regions go offline. The connection to an inference endpoint is no more reliable than any other network call, and treating it as a transparent function (write the prompt, get the answer) is how a demo becomes an outage.
The input is sometimes weird. Users paste in forty pages of unrelated text. They write in a language the prompt wasn’t designed for. They send messages that look adversarial whether or not they were intended that way. The space of real inputs is much larger than the space of inputs the demo showed.
The bill is sometimes huge. A feature that costs four cents per call costs four thousand dollars per day the moment it goes viral. Without per-user and per-feature cost tracking, the first warning a team gets is the monthly invoice.
These aren’t theoretical risks. They’re the four failure modes we see most often when we’re brought in to fix an AI feature that worked fine in testing.
What makes an AI feature production-ready
Production-ready is a list of things the demo didn’t have to do.
Evals, not vibes. Before the feature ships, there’s a test set. Real inputs (or representative synthetic ones), expected outputs or quality criteria, and an automated way to grade the model against them. When you swap the prompt, the model, or the temperature, the evals tell you whether quality went up or down. Without evals, every change is a guess and every regression is invisible until a customer complains.
Retries with backoff, and a fallback path. The model call sits behind a retry policy with exponential backoff for transient errors, and a defined fallback for the case where the model is unavailable. Sometimes the fallback is a smaller model. Sometimes it’s a cached answer. Sometimes it’s a polite “we’re having trouble, try again in a minute.” It is never silently breaking the feature. A model-agnostic architecture makes this much cheaper to set up than retrofitting it later.
Observability you can actually use. Every model call is logged with input, output, latency, token counts, cost, and a sampling rate that lets a human review a representative slice rather than every call. When something goes wrong, you can find the bad calls in minutes, not days. When the model starts behaving differently because a provider updated something underneath you, you can see it in the metrics before customers see it in the product.
Cost monitoring at the feature level. Spend tracked per feature, per user tier, and per call. Alerts when daily spend crosses a threshold. A hard cap somewhere in the system so that a runaway loop or an abusive user can’t drain the budget overnight.
Guardrails on input and output. Inputs filtered or constrained where the model is sensitive (system prompt injection, off-topic queries, sensitive categories). Outputs validated against the structure the rest of the system expects, so a malformed response doesn’t crash the next step in the pipeline. Where the output is shown to users, a content review layer if the risk profile demands it.
A way to know when the model is wrong. Sometimes that’s user feedback (thumbs up, thumbs down, “this isn’t what I asked for”). Sometimes it’s downstream signals (the user re-asked the question, the user didn’t click the suggested action, the conversation was transferred to a human). Sometimes it’s periodic sampling against the eval set. Without one of these, the model’s quality drifts and nobody notices.
None of these are exotic. They’re the boring infrastructure that turns a model call into a feature.
What this looks like in practice
The streaming AI code generator we built for a global user base ships with the full stack: evals on every prompt change, multi-provider fallback, per-language quality monitoring, token-level cost tracking, and a feedback signal that catches regressions before users do. That’s not because the project was overbuilt. It’s because none of it could be skipped without the feature falling over in the first week.
A different client came to us with an AI assistant their previous team had shipped. The model was fine. The prompt was fine. What they were missing was the scaffolding: no evals, no logging beyond raw API responses, no cost dashboard, no retries, no way to tell whether the assistant was getting better or worse over time. The fix wasn’t a better prompt. It was the engineering around the prompt.
That gap is the most common reason an AI feature that looked good in a demo ends up quietly switched off six months later. The team ran out of patience trying to debug a system they couldn’t see into.
The same operational discipline applies across categories of AI feature. For voice AI specifically, where it pays off and where it still doesn’t is a separate question; the scaffolding above is what makes the use cases that do fit hold up in production.
How to evaluate an AI vendor before signing
If you’re commissioning an AI integration, the questions below test whether the vendor builds for production or for the demo. The exact answers depend on the project. The shape of the answers matters more than the specifics.
1. How will we know if the model is getting worse? Looking for: evals, sampled review, user feedback signal, regression alerts. The wrong answer is “we’ll keep an eye on it” or “we’ll know if customers complain.”
2. What happens if the model provider has an outage? Looking for: retries, fallback model or fallback path, graceful degradation. The wrong answer is silence on this question, or “their uptime is good.”
3. How are we tracking cost per feature and per user? Looking for: per-call logging, per-feature breakdown, alerts, a hard cap. The wrong answer is “we’ll look at the monthly bill.”
4. What’s the test set you’ll use before changing the prompt or model? Looking for: a real eval set with grading criteria, run automatically when changes ship. The wrong answer is “we’ll test it manually.”
5. If a user sends a malicious or off-topic input, what happens? Looking for: input validation, system-prompt isolation, output structure checks. The wrong answer is “the model handles that itself.”
A team that can answer all five with grounded specifics builds AI features that survive their first month in production. A team that pivots or stays vague on more than one or two is selling a demo.
The boring part is the work
The interesting part of AI engineering, the part that gets written about, is prompts and model selection and the latest paper. The part that determines whether an AI feature stays running for a year is the boring part: tests, retries, logs, dashboards, alerts, caps. The work that nobody writes about because it looks like normal software engineering.
That’s because it is normal software engineering. The model is a new component. The discipline of shipping production software around it isn’t new at all. Teams that already build serious software apply the same discipline to AI features and ship things that hold up. Teams that treat the model as magic ship demos and then ship bug reports.
Have an AI feature you’re trying to make production-ready, or one you’re about to commission? Tell us what you’re building. We respond within one business day with the gaps we see and a rough scope for closing them.