Insights · AI · 15 July 2026
Does your product actually need AI?
We build AI products, and we still say no to half the AI ideas that reach us. Here is the checklist we use, so you can run it before paying anyone.
The board wants to know the AI strategy. The competitor just shipped a chatbot. Somewhere in the building, a demo is being polished that will absolutely amaze everyone right up until real users touch it.
We build AI products for a living, we run one of our own, and we still turn down half the AI ideas that reach us. Not because the models are weak, but because the feature being imagined fails one of three questions that take ten minutes to ask. Here they are, so you can run them before paying anyone.
Question one: is the task language shaped or judgement shaped?
Modern AI earns its cost on a specific family of work: summarising, drafting, extracting, classifying, translating between formats, and answering questions over a body of documents. If your feature lives in that family, the technology is genuinely ready for it.
It wastes its cost on work a database query or a rules engine does perfectly. A surprising number of pitched AI features are rules engines wearing a costume: if the correct behaviour can be written as a table of conditions and outcomes, write the table, because it will be faster, cheaper, and right every single time.
Question two: what happens when it is wrong?
Every model is sometimes wrong. This is not a flaw to engineer away, it is a property to design around, and it splits all AI features into two families.
In the first family, a wrong answer is visible and cheap: a draft you edit, a suggestion you skip, a summary you sanity check. The human is already in the loop, and the feature saves time even at ninety percent accuracy. Ship these with confidence.
In the second family, a wrong answer is silent and expensive: a price quoted, a claim assessed, a diagnosis suggested, an email sent on your behalf to a customer. These need a human checkpoint, a guardrail, or the honest decision not to build them. The feature's viability is not the model's accuracy. It is the cost of the residual errors, and that cost is a product decision, not a technical one.
Question three: would users notice if you removed it?
The market stopped rewarding the word AI some time ago. Users have seen a hundred chat boxes bolted onto products that did not need them, and they can smell a press release feature at one glance.
The test is removal. If your imagined feature vanished a month after launch and users would shrug, you are buying an announcement, not a capability. If they would complain, because it was saving them an hour a week, build it.
What doing it properly actually costs
The model API is the cheap part of the bill. The real costs are three, and skipping them is how demos decay into embarrassments.
The quality bar: a test suite of real examples with known good answers, written before the feature, run on every change. It is the difference between knowing your quality and hoping for it. The uncertainty design: interfaces that show confidence honestly, make correction easy, and fail gracefully, which is product work, not prompt work. And the monitoring: models change underneath you, costs drift per request, and quality can sag without a single line of your code changing. Someone has to be watching.
Budget those three and AI features hold up in month six the way they demoed in week one. Skip them and the gap between demo and product becomes your users' problem, then your reputation's.
The one week answer
Before committing a quarter to an AI roadmap, spend a week: take one real workflow, collect fifty real examples of it, and measure whether a model plus your data beats what users do today. Fifty examples will tell you more than every opinion in the building.
That evidence costs a week. The wrong AI feature costs a quarter and a headline. And if the week says no, that answer is worth exactly as much as a yes, because the market no longer rewards having AI. It rewards AI that works.