Trust Is the Feature: Building AI Products People Believe
The hardest problem in AI products isn't capability — it's earning enough trust that people act on the output. Here's how I design for it.
Most AI demos are impressive. Most AI products are abandoned. The gap between the two is rarely capability — it's trust. A model that's right 95% of the time sounds great until you realize users can't tell which 5% to ignore.
I've built two AI products to real usage, and the same lesson kept surfacing: trust is the feature. Everything else is table stakes.
Why accuracy alone fails#
A confidently wrong answer is worse than no answer. When an analytics copilot returns a revenue number that's subtly off, the user doesn't just distrust that number — they distrust the entire tool, and they tell their team.
The math is brutal:
- A tool that's 99% accurate but opaque gets abandoned after the first visible miss.
- A tool that's 90% accurate but transparent gets adopted, because users can verify and correct it.
Transparency compounds. Opacity decays.
Ground the model, don't just prompt it#
The single biggest lever for reliability is constraining what the model can say. Instead of open-ended text-to-SQL, I route generation through a governed semantic layer, so the model plans against blessed metrics rather than raw tables.
type SemanticQuery = {
metric: "revenue" | "active_users" | "churn_rate";
dimensions: string[];
filters: Filter[];
grain: "day" | "week" | "month";
};
// The model produces this structure — not raw SQL.
// A deterministic compiler turns it into a safe, correct query.
function compile(query: SemanticQuery): SQL {
return planner.build(query);
}By turning an open-ended problem into a bounded one, accuracy jumps and, more importantly, failures become legible.
Make the model say "I'm not sure"#
Coverage is seductive. Resist it. I add a verification pass that re-checks generated output against the schema and refuses anything referencing unknown fields.
Trading a handful of "I can't answer that" responses for zero confidently-wrong ones is almost always the right deal.
Show the work#
Every answer ships with the query it ran and the rows it touched. This does two things:
- It lets skeptical users verify results themselves.
- It turns power users into collaborators who fix your edge cases for you.
Perceived performance is a design problem#
Users tolerate latency if they see progress. Streaming the pipeline in stages — plan, then query, then chart — cut perceived wait time roughly in half without changing total compute.
The takeaway: in AI products, your job isn't to build the smartest system. It's to build the most trustworthy one. Capability gets the demo. Trust gets the retention.