Shipping AI features that don't feel like AI features

The first version of the AI feature was impressive. Users opened it once, said 'cool,' and never came back. The second version was quieter. They used it every week.

When you're building AI features for the first time, it's easy to design around the capability. The model can do something impressive: detect a pattern, generate an insight, surface a connection. The instinct is to show that off. Lead with what the technology can do.

What I found, building the analysis layer for Unsaid, is that impressive is a low bar. Impressive is a demo emotion. Useful is a Tuesday emotion. The features that survive past the first week are the ones that do something specific enough to be worth returning to, even when the novelty is gone.

The tiering decision

Unsaid's AI pipeline has three tiers. The first runs per entry: lightweight pattern detection that gives immediate feedback after a user submits a journal. The second runs weekly: a synthesis across all entries, looking for recurring themes, emotional patterns, behavioral loops. The third is on-demand: deeper analysis triggered when a user asks a specific question.

Each tier has different latency requirements, different costs, and different value. The per-entry tier needs to be fast, because the user just submitted something and is waiting. The weekly synthesis can run overnight. The on-demand tier needs to feel responsive, because the user asked something and is expecting an answer.

These decisions came from asking a different question: not 'what can the model do?' but 'what does the user need, and when do they need it?'

The mistake of leading with the model

The first version showed users a list of everything the model had found. Every pattern. Every connection. Every detected theme across every entry. It was thorough. It was technically impressive. Nobody came back to it.

The problem wasn't the quality of the analysis. It was that I'd designed around the output of the model, not around what was useful to the user in a specific moment. A user who just journaled doesn't want a comprehensive analysis. They want one thing to think about. A user reviewing their week doesn't want raw data. They want a narrative.

Designing around what the model can do is a different problem than designing around what the user needs.

The question I now ask

Before adding any AI feature, I ask one question: would a user notice if I removed this? Not in a 'they'd miss it in theory' sense. In the sense of: is there a specific moment in the product where this feature solves a concrete problem for them? If I can't describe that moment, the feature isn't ready. It might be impressive. It might work. But it doesn't belong yet.

This question cuts a lot of AI features that felt valuable when I was building them and would have felt like noise once shipped.

What quiet AI looks like

The AI features that work in Unsaid are the ones that feel like they were always supposed to be there. The per-entry pattern label isn't framed as 'AI detected this.' It's just a word that appears after the entry, small and confident. The weekly synthesis doesn't begin with 'here's what your AI has found.' It opens with an observation, directly, the way a person would.

This took deliberate work. The framing, the copy, the placement, all of it was designed to make the AI layer feel like part of the product, not a capability demonstration. The model does the same work either way. What changes is whether the user experiences it as a product or as a feature.

Users don't want to feel like they're using AI. They want their problem solved. The AI is most useful when it's the most invisible.