How we ship AI features that survive real users
A field guide to taking assistants from a slick demo to a dependable product feature.
The demo always works. That is the trap.
An AI feature that dazzles in a five-minute walkthrough can quietly fall apart the moment real users — with messy inputs, edge cases and impatience — get their hands on it. Over the last two years we have shipped assistants into healthcare, fintech and internal tooling. The pattern that separates the ones that stuck from the ones that got quietly switched off is remarkably consistent.
Start with an evaluation set, not a prompt
Before writing a single line of the feature, we write the test. We collect 30–100 real examples of the task — actual support tickets, actual documents, actual questions — and hand-label the ideal output for each. This becomes our eval set, and we treat it exactly like a unit test suite.
Every prompt change, model swap or retrieval tweak runs against the full set. If a "small improvement" regresses six other cases, we see it immediately. Without this, you are tuning by vibes, and vibes do not scale past the third stakeholder.
A prompt without an eval set is a guess with good production values.
Retrieval beats a bigger model
Most business AI features are not reasoning problems — they are grounding problems. The model is perfectly capable; it just does not know your data. Retrieval-augmented generation (RAG) — fetching the right context and putting it in front of the model — outperforms a larger, ungrounded model almost every time, at a fraction of the cost.
The hard part is not the vector database. It is chunking, ranking and knowing when you have retrieved nothing useful and should say so.
Guardrails and graceful failure
Three rules we never break:
- Every AI call has a fallback. If the model times out, returns nonsense, or the safety classifier declines, the user gets a sensible canned response — never a spinner of death or a raw error.
- Cite your sources. When an assistant answers from your docs, it links to them. Users trust what they can verify, and citations make hallucinations obvious.
- Constrain the output. Structured outputs and strict schemas turn "please respond in JSON" hope into a guarantee.
Keep a human in the loop
For anything where a wrong answer is expensive — a medical triage suggestion, a financial figure, a legal summary — the AI drafts and a human approves. This is not a failure of ambition; it is the design. The assistant removes 80% of the manual effort while the human retains accountability for the last mile.
Ship narrow, then widen
The fastest way to kill trust in an AI feature is to launch an omniscient assistant that is confidently wrong about half of what it touches. We launch the narrowest useful version — one task, one workflow — measure it against the eval set and real usage, then expand only once it has earned the confidence.
That is the whole game: evals up front, retrieval over raw model size, guardrails everywhere, humans where it matters, and disciplined scope. Do that and your AI feature will still be running a year later — not quietly disabled after the launch buzz fades.
Frequently asked questions
How long does it take to ship a production AI feature?
A focused, well-scoped assistant typically takes 4–8 weeks from kickoff to production, including the eval set, retrieval pipeline, guardrails and a human-in-the-loop review step. The timeline depends far more on data readiness than on model choice.
Do we need to train or fine-tune our own model?
Almost never. For the vast majority of business use cases, a capable general model plus good retrieval (RAG) outperforms a fine-tuned smaller model, ships faster and costs less to maintain. We reach for fine-tuning only for narrow, high-volume, well-defined tasks.
How do you stop the AI from hallucinating?
You cannot eliminate it entirely, but you can make it rare and obvious: ground answers in retrieved context, require citations the user can click, constrain outputs with strict schemas, and keep a human approval step wherever a wrong answer is costly.
What does it cost to run?
Retrieval-based features are surprisingly affordable — most of the cost is engineering, not inference. Grounding a capable model with the right context is far cheaper than running an oversized model on every request.
Keep exploring
Enjoyed this? We build the things we write about.
From first sketch to scaled platform — let's talk about your project.
Start a project
