Key takeaways
- Define the job and success metric before writing prompts
- Build a small eval set from real user scenarios first
- Ship with fallbacks, cost caps, and human handoff from day one
Most AI features die between the demo and the first real users. The prompt looks clever in a slide deck. Then latency spikes, costs climb, edge cases pile up, and the team quietly turns the feature off.
“If you can’t measure quality, you don’t have an AI product - you have a demo.”
Start with the job, not the model
Before you pick a model, write one sentence: what decision or task does this feature take off a human’s plate? If the answer is vague (“make the product smarter”), stop. Narrow it to a job with a measurable outcome - draft a reply, extract fields, rank options, summarize a ticket.
- One primary user job, stated in plain language
- A success metric you can score (accuracy, time saved, resolution rate)
- A clear non-goal (what the model must not invent or decide alone)
- An owner for quality after launch - not “the AI person when free”
Eval before prompts
We build a tiny evaluation set before we polish prompts. Twenty to fifty real-ish scenarios is enough to start. Include the messy ones: empty input, hostile users, multilingual text, PII, and the cases where “I don’t know” is the right answer.
- 01
Collect scenarios
Pull from support tickets, sales calls, or product analytics - not invented happy paths.
- 02
Label expected behavior
For each scenario, define a good answer shape, a refuse condition, or a handoff trigger.
- 03
Score every change
Prompt, model, or retrieval change only ships if the eval set holds or improves.
Production is a system, not a prompt
Graceful degradation is non-negotiable. If the model is slow, wrong, or unavailable, users should still finish the job - with a cached answer, a simpler rule path, or a human handoff.
<2s
Target p95 latency for interactive AI UX
3×
Cost spike without per-request caps
1
Fallback path required before launch
Cost and safety gates
- Hard caps per request and per user/day - not “we’ll watch the bill”
- Output validation before anything hits the UI or writes to a database
- PII redaction on inputs that leave your boundary
- Kill switch: disable the AI path without redeploying the whole app
What “done” looks like
An AI feature is ready when a new engineer can read the eval set, the fallback map, and the cost limits - and know how to improve quality without guessing. Prompts alone are not the product. The product is the system around them.
