By the end of 2025, we'd shipped twelve LLM features to production across six industries. Here's the uncomfortable pattern: the ones that failed did not fail because the model was wrong. They failed because the system around the model was wrong.
Start with the eval set, not the demo
The single highest-leverage decision in any LLM project is writing the labelled evaluation set before you pick a model. Not after. The set should contain the 200 hard questions your product will actually be asked — collected from support tickets, not invented in a design doc.
If you can't explain, in numbers, what "good" means, you will ship a demo that works and a product that doesn't.
Retrieval is 80% of the game
In every RAG failure we've debugged, the bottleneck was retrieval quality, not generation. Hybrid search — keyword + vector — with good chunking and metadata filters consistently beats pure vector search. Measure recall@10 on your eval set before you look at one generated answer.
retrieval tests pass → generation tests pass retrieval tests fail → nothing else matters
Guardrails that route, not block
The best guardrail layer we've built doesn't reject low-confidence answers. It routes them: answer with citation when confidence is high, offer a callback form when it's medium, and page a human when it's low. Your first customer experiences calm competence, not a wall.
The production checklist
Before a single user sees your feature, we want to see: an eval harness in CI, cost-per-output instrumentation, streaming responses, a human handoff path, and a rollback that doesn't require a migration.
Do that, and your AI feature will be remembered for being quietly useful — which, frankly, is the point.
If you would rather not build this alone, it is the work our applied-AI practice does every week — sitting on the same data engineering foundations every retrieval system needs.