The unglamorous checklist that gets LLM features into production

Every company we talk to has an impressive AI demo. Very few have that demo running in production a year later, and the gap is rarely the model. It's the scaffolding nobody budgets for: evaluation, failure handling, and cost discipline. After shipping a dozen LLM features into production — claims triage, research search, support assistants — we've distilled the checklist we now run before any AI feature scales past a pilot.

None of it is glamorous. All of it is the difference between a feature and a liability.

Build the golden dataset before the feature

The single highest-leverage artifact in an AI project is a few hundred real examples with known-correct answers — actual documents from your archive, actual tickets from your queue, including the ugly ones with scanned handwriting and contradictory fields. Assembling this dataset feels like a delay. It isn't. It's the only way to know whether your accuracy is 94% or 71%, and every prompt change, model swap, and retrieval tweak for the life of the feature will be judged against it.

A practical note: source your examples from the worst month in your archive, not the best. Systems tuned on clean inputs meet dirty reality with confidence and wrong answers — the most expensive combination.

Decide what happens when the model is wrong

The model will be wrong. The design question is what happens next, and it must be answered per use case: a wrong product recommendation costs a click, a wrong medication extraction costs something unthinkable. We force every feature through the same question — what is the cost of a confident wrong answer, and who catches it? The answer determines whether output goes straight to users, through confidence-threshold routing, or behind mandatory human review.

Confidence routing deserves more attention than it gets. Most production systems we build auto-handle the easy 80% and route the uncertain 20% to humans with context pre-assembled. That split preserves nearly all the efficiency gain while capping the downside — and it gives your team a review queue that doubles as a training-data pipeline.

Model the unit economics at real volume

A feature that costs $0.04 per request is a rounding error in a demo and a $480,000 annual line item at a million requests a month. Before scaling anything, we model cost per interaction at projected volume — then engineer against it. Caching identical and near-identical requests, routing simple cases to smaller models, and trimming bloated prompts routinely cut serving costs 60–80% with no accuracy loss.

The teams that skip this step don't discover it during the pilot. They discover it in the third month of the invoice, which is a bad month to redesign an architecture.

Make regressions visible before users do

Prompts are code. Model versions are dependencies. Both change, and both can silently degrade a feature that was working last Tuesday. The golden dataset becomes your regression suite: every prompt edit and model update runs against it in CI, with accuracy deltas reported like test failures. This is boring engineering applied to a novel domain — which is precisely the point. The novelty is in the capability; the reliability comes from treating it like software.