Shipping an LLM feature to production: an engineering checklist
Getting a prototype to work takes a day. Getting it to work reliably, affordably, and safely for real users takes engineering. This is the checklist we use.
Oct 26, 2026 · 3 min read
LLM prototypes are deceptively easy. A good prompt and an API key get you an impressive demo in an afternoon. Then real users arrive with messy inputs, edge cases, and expectations, and the demo starts to wobble.
This is the checklist we work through before an AI feature goes to production.
1. Define the task and the success metric
"Add AI to support" is not a task. "Draft a reply to order-status tickets that an agent can send with minimal edits" is. Write down:
- The exact input and output.
- Who uses the output, and what they do with it.
- How you'll measure success, whether that's acceptance rate, edit distance, time saved, or accuracy on a labeled set.
2. Build an evaluation set before you tune anything
Collect real examples, ideally from production data with sensitive fields redacted, and write down what a good answer looks like for each. Even a modest set of carefully chosen cases is enough to tell whether a prompt or model change made things better or worse.
Run the evals on every change, the same way you'd run tests.
3. Ground the model in your data
Most business features need context the model doesn't have. Retrieval (RAG) over your documents and databases is usually the right first step:
- Measure retrieval quality separately. If the right document isn't retrieved, the answer can't be right.
- Return sources with answers so users can verify them.
- Respect permissions: users should only retrieve what they're allowed to see.
4. Constrain the output
Free-form text is hard to integrate and hard to check.
- Ask for structured output against a schema and validate it.
- Reject or retry invalid responses instead of passing them downstream.
- Keep the model's job narrow; use regular code for anything deterministic.
5. Add guardrails and human review
- Filter inputs and outputs for sensitive data and off-topic or unsafe content.
- Route low-confidence or high-impact outputs to a review queue.
- Never let the model take irreversible actions, such as payments, refunds, or account changes, without approval and an audit trail.
6. Budget for cost and latency
- Set a per-request cost and latency budget early, and track both in production.
- Use smaller, faster models for simple steps and reserve larger models for hard ones.
- Cache repeated work, and stream responses when users are waiting.
7. Observe everything
- Log prompts, retrieved context, outputs, and user feedback, with PII redacted.
- Version prompts like code, so you can tie a quality change to a specific release.
- Watch for drift. Input patterns change over time, and so will quality.
8. Plan for failure
Providers have outages and rate limits. Decide in advance what users see when the AI step fails: a graceful fallback, a retry, or the non-AI path. The feature should degrade, not break.
9. Check the data terms
Before production, confirm what your provider does with your data: retention, training use, and where it's processed. In regulated industries, this belongs in the same review as any other vendor handling customer data.
Treat the model as one unreliable component inside a reliable system. The engineering around it is what makes the feature trustworthy.
None of these steps is glamorous, but together they're the difference between an AI demo and an AI product.