Where AI actually earns its place in a product
We ship AI features when they remove a step for the user, not when they're the easiest thing to demo.
The AI features that survive contact with real users are the boring ones: the ones that quietly remove a manual step, not the ones built to impress in a five-minute demo.
Demos reward the opposite instinct. A chat box on the homepage demos beautifully and answers questions nobody was asking. A model that reads a photographed receipt and fills in four form fields demos poorly and saves someone twenty minutes a day. We would rather build the second one.
The test we apply
Before we agree to build an AI feature, we ask what step it removes. Not what it adds: what it removes. If the honest answer is "it makes the product feel modern," the feature is decoration, and decoration is expensive to run and awkward to withdraw once users have seen it.
Removing a step is a specific claim. Someone was typing something, or copying between two systems, or waiting for a colleague to categorise something. After the feature ships, they aren't. You can watch that happen, and you can measure it without instrumenting anything clever.
Three questions before we ship
What happens when it's wrong? Not if. Every model is confidently wrong on some input, and the input that breaks it will arrive on a Tuesday from your largest customer. If a wrong answer is cheap to notice and cheap to undo, the feature is a good candidate. If a wrong answer is invisible and compounds, it isn't, no matter how good the accuracy looks on your test set.
Who checks it? The best AI features we've built put a person in the loop at the point where they were already working. Extract the fields, then show them filled in, editable, before anything is saved. The user reviews as a side effect of the task they were doing anyway, rather than as new work you've handed them.
What's the fallback? Model providers have outages, rate limits and deprecations. If the feature has no non-AI path, then a provider incident is a product outage. Usually the fallback already exists: it's the manual flow the feature replaced, and keeping it reachable costs almost nothing.
Where it has earned its place
The pattern that keeps working is turning messy input into structured data: pulling fields out of documents and photographs, classifying free text into categories a system already understands, matching an entry against records that are spelled six different ways. This is the unglamorous middle of a lot of African business software, where the input is a scan, a photo or a WhatsApp message, and the alternative is a person retyping it.
Search over an organisation's own documents is the other one. Not a chatbot persona, just the ability to ask a question and get the paragraph that answers it, with a link to the source so the reader can check.
Drafting sits in between. It works when the output is a starting point someone edits, and it fails when it's presented as finished.
Where we've left it out
We've talked clients out of AI more than once. The consistent reason: a wrong answer that the user has no way to evaluate. If someone cannot tell a good output from a plausible bad one, and the consequence lands on them rather than on the system, that feature transfers risk to the person least equipped to carry it.
Anything involving someone's money, eligibility or medical record deserves that scrutiny before the model is chosen, not after.
Cost and latency are product decisions
Two things that get treated as infrastructure details and shouldn't be.
Every call has a price, and per-user costs behave differently from server costs: they scale with success. A feature that's marginal at a thousand users can be the largest line in the bill at fifty thousand. That belongs in the decision to build it, not in a bill six months later.
Latency is the same. A response that takes eight seconds is a different feature from one that takes eight hundred milliseconds, even with identical output. On a patchy mobile connection, which is the normal case in the markets we build for, the difference decides whether the feature gets used at all.
Boring beats impressive
None of this is an argument against the technology. It's an argument for applying the same standard to it as everything else in the product: does it remove work, can the user tell when it's wrong, and does the product still function when it fails.
The features that pass are rarely the ones anyone demos. They're the ones people would complain about losing.