Putting Claude into production: what actually breaks, and how to prevent it

Every Claude project we inherit has the same origin story. Someone built a prototype in an afternoon, showed it to the business, and the room lit up. Six weeks later the same system is in production and nobody trusts it.

The model rarely turns out to be the problem. What breaks is everything around it — the assumptions that held for ten test cases and quietly stopped holding at ten thousand. Here is what we check before anything of ours goes live.

Where the gap actually opens and closed

A demo is a happy-path system. You choose the inputs, you’re watching when it runs, and if something looks wrong you re-run it. Production removes all three of those comforts at once: inputs are adversarial or just strange, nobody is watching, and the first re-run is a support ticket.

That shift produces six failure modes, and they show up in roughly this order.

Reliability: design the bad path first

The same prompt does not reliably produce the same shape of answer. That is not a defect, it is how the technology works — but it means any code that assumes a fixed structure will eventually receive something it cannot parse.

Treat every model response as untrusted input:

• Validate the shape, not just the content. If you expect JSON, parse it and check the schema before anything downstream touches it.
• Decide what a failed response does. Retry once with a tightened prompt, fall back to a deterministic path, or tell the user honestly — but decide, don’t discover.
• Constrain the output surface. Tool definitions and structured outputs eliminate whole categories of parsing failure that prompt instructions alone will not.

The teams who skip this usually don’t find out for weeks. Then a single malformed response takes down a workflow, and the incident review concludes the AI is unreliable — when what was unreliable was the code around it.

Context: retrieval gets greedy

Retrieval that looks precise in testing tends to sprawl in production. Real queries are vaguer than test queries, so the retriever returns more, and someone raises the top-k to compensate. Now every call carries three times the context it needs.

Two things keep this in check. Cap what you pass and rank it properly — relevance ordering matters more than volume. And log what was actually retrieved for a sample of real calls, because the gap between what you think you’re sending and what you’re sending is where both cost and quality problems hide.

Once you have the number, the levers are straightforward: stream responses so perceived latency drops even when total time doesn’t, move anything that isn’t blocking into an asynchronous job, and cut prompt size before you start optimising anything else.

Cost: the invoice is a lagging indicator

Usage-based pricing behaves very differently from the licence costs most finance teams are used to. A feature that costs almost nothing in pilot can become a material line item the month it reaches the whole organisation — and you find out thirty days late.

• Instrument cost per call, not just total spend. Aggregate figures hide the one workflow that’s burning the budget.
• Cache aggressively. A surprising share of production traffic is the same question asked slightly differently.
• Route by difficulty. Not every request needs your most capable model. Matching model to task is the single largest cost lever most teams leave untouched.
• Rate-limit per user and per tenant. This protects you from bugs and abuse equally.

Security: the model is a new attack surface

Standard application security still applies — keys in a secrets manager, never in client code; authentication and authorisation on every call. But an AI system adds a problem most teams haven’t dealt with before: text that reaches the model can attempt to change its behaviour.

If your system retrieves documents, reads emails, or accepts anything a user supplies, assume that content may contain instructions. Defend structurally rather than with prompt wording:

• Keep the model’s permissions narrower than the user’s — it should never be able to reach data the person couldn’t reach directly.
• Put a human in the loop for anything irreversible: payments, deletions, outbound communication.
• Validate tool arguments server-side. A tool call is a request, not an instruction you’re obliged to honour.
• Send the minimum data required. The safest sensitive field is the one that never left your database.

Observability: you cannot improve what you cannot see

Conventional monitoring tells you the service returned 200. It does not tell you the answer was wrong. AI systems need a second layer of observation, and it has to exist from day one rather than being added after the first complaint.

At minimum, log inputs and outputs with a retention policy your legal team has agreed to, plus latency, token usage and cost per call. Then add the part most teams miss: a feedback signal. A thumbs up and down on every response, reviewed weekly, will teach you more about quality than any offline evaluation suite.

The pre-launch checklist :

This is what we run before an engagement goes live. If any line is unanswered, it isn’t ready.

• Every model response is schema-validated before use
• A defined fallback exists for timeout, malformed output and refusal
• Context size is capped, and we can see what was actually retrieved
• A latency budget is written down and measured against
• Cost per call is visible, with alerting on the trend
• Rate limits are set per user and per tenant
• The model’s data access is narrower than the user’s
• Irreversible actions require human confirmation
• Inputs, outputs, latency and cost are logged with an agreed retention policy
• A user feedback signal exists and someone owns reviewing it

The difference between a demo and a system is what happens on the bad path.

None of this is exotic. It is the same engineering discipline any production system deserves, applied to a component that happens to be probabilistic. Teams that treat Claude as infrastructure rather than as a feature get there faster — and stay there.

If you’re moving an AI system from pilot to production and want a second pair of eyes on it, start a conversation. You’ll be talking to the people who do the work.