LLM features that survive contact with real users
Six patterns we now apply to every AI feature we ship — drawn from the ones that worked and, more usefully, the ones that did not.
We have shipped model-backed features in a companion app, a fasting guide and an app-permission explainer. Different domains, the same recurring lessons.
1. Constrain the surface before the prompt
An open text box is the hardest possible product to get right. Every feature that worked for us started from a narrow entry point — a specific button, on a specific screen, with the context already attached. Prompt engineering matters far less than deciding what the user is invited to ask.
2. Never let the model own facts
Dates, prices, permissions, legal text — these come from code or a database. The model rewrites and explains them. Where we blurred that line we shipped confident, wrong answers, and a confident wrong answer costs more trust than no answer at all.
3. Latency is a feature, not a metric
A two-second response that streams feels faster than a one-second response that arrives all at once. Streaming was the single highest-impact change we made to perceived quality, and it required no model change.
4. Fail into something useful
When the model is unavailable, the feature should degrade to its non-AI ancestor: a search box, a static explainer, a list. An error dialog teaches users that the feature is unreliable.
5. Log the questions, not the answers
The most valuable artefact from any AI feature is what people tried to ask. Much of our roadmap for Rilwa came from reading anonymised question shapes and noticing what users expected the app to already do.
6. Write the refusal copy yourself
Every model declines things. If you do not write those messages, the model writes them, and they will not sound like your product. We keep an explicit list of out-of-scope categories with our own wording for each.
The model is the cheapest part of an AI feature. Everything around it is the product.
Published Jul 4, 2026 · 2 min read