Shipping LLM Features to Production: A Reliability Checklist

A large language model demo takes an afternoon. A large language model feature that survives real users, real edge cases, and a real invoice takes considerably longer. The gap between the two is where most AI projects quietly die.

This is the checklist we run before any LLM feature ships to a client's production environment.

1. Define the task narrowly

Broad prompts produce broad, unreliable behaviour. The most reliable LLM features do one small thing: classify this ticket, extract these fields, draft this reply. Before writing a prompt, we write the input contract and the output contract.

• Input: what exactly is passed in, and in what format.
• Output: a strict shape — ideally JSON validated against a schema — not free prose the rest of the system has to parse.

2. Build an evaluation set before the prompt

You cannot improve what you cannot measure. Before tuning anything, we collect 30–100 real examples with known-correct answers. This is the single highest-leverage step, and the one teams skip most often.

type EvalCase = {
  input: string;
  expected: string;
  mustContain?: string[];
  mustNotContain?: string[];
};
 
function scoreCase(output: string, c: EvalCase): boolean {
  if (c.mustContain?.some((s) => !output.includes(s))) return false;
  if (c.mustNotContain?.some((s) => output.includes(s))) return false;
  return true;
}

Every prompt change is then measured against the eval set. A change that improves one example but regresses three is rejected automatically.

3. Constrain the output

Free-text output is a liability. We constrain it in the strongest way the task allows:

• Structured output validated against a schema, with a retry on validation failure.
• Enumerations for classification — the model chooses from a fixed list, not an open field.
• Refusal paths — an explicit "I do not know" option so the model can decline instead of inventing.

4. Plan for failure

Every LLM call will eventually time out, rate-limit, or return something wrong. Production features need a defined behaviour for each:

• Timeouts and retries with sensible backoff.
• A deterministic fallback — a rules-based path or a graceful "a human will follow up" message.
• Never fail silently. Log the input, output, and failure reason for every miss.

5. Keep a human in the loop where it matters

For anything consequential — money, contracts, medical or legal decisions — the model drafts and a human approves. This is not a limitation to apologise for; it is the correct architecture. The AI removes the blank page; the human keeps the accountability.

6. Watch cost and latency from day one

Token cost and response time are product features, not afterthoughts. We track cost-per-request and p95 latency in the same dashboard as accuracy, because a feature that is correct but too slow or too expensive is still a failed feature.

The one-line summary

An LLM feature is production-ready when it has an evaluation set, a constrained output, a defined failure path, and a monitored cost — not when the demo looks good.

Frequently asked questions

Do we need fine-tuning?

Usually not first. Strong prompting, retrieval, and constrained output solve the majority of tasks. Fine-tuning is worth it once you have an eval set proving a consistent, specific gap that prompting cannot close.

How do we stop hallucinations?

You reduce them, you do not eliminate them: ground the model in retrieved facts, constrain the output, give it a refusal path, and keep a human check on high-stakes decisions.

If you are building an AI feature and want it to survive contact with real users, book a strategy call and we will pressure-test the plan with you.