Where AI belongs in a digital product

The question that decides whether an AI feature works is almost never the one we get asked.

Clients arrive with a model in mind. What the product needs first is a decision about what it does when that model is wrong. That decision turns out to be most of the work, and the prompt, the retrieval and the evaluation set all follow from the answer.

Three shapes that hold up

Nearly everything we have shipped falls into one of three shapes.

The first answers questions from material the business already owns: policy documents, product manuals, three years of support tickets. The model does not know your refund policy. It knows how to read the page that contains it, which is a smaller and far more reliable job. The engineering is mostly retrieval, and retrieval can be inspected, so when an answer comes out wrong you can see which document it came from. Usually the document is what needs fixing.

The second sits inside the product and does one narrow thing. Summarising a long thread before a call. Drafting a message the user then edits. Reading a photographed invoice into fields the user checks. The person stays in charge; the feature proposes and they dispose.

The third runs a repeatable process from one end to the other, pulling a file, checking it against rules, filing what passes and flagging what does not. This is where the real gains are and it needs the most care, because there is nobody standing between the model and the outcome.

Work that fits none of the three is usually a research project wearing a product's clothes. It can still be worth doing. It should be budgeted as research.

Design the wrong answer first

A model that is right nine times in ten is a decent model and a poor product, if the tenth answer arrives looking exactly like the other nine.

So the failure gets designed before the success. Where does uncertainty become visible? What can the user do about it? Is there a route back to a person, and does that route carry the context so nobody has to repeat themselves? For anything touching money, is there a step where somebody confirms before it commits?

In the interface that comes down to a few habits. Show the source, so an answer can be checked without leaving the screen. Make output editable rather than final. Keep a visible record of what the system did on someone's behalf. And give people a way to report a bad answer that reaches a human, because complaints that vanish are how a quality problem stays invisible.

The bar moves with what the feature touches. A summarising assistant on a support inbox can be wrong occasionally and still earn its place. The same tolerance applied to an affordability check, or to a transaction categorisation that feeds a statement, is a different proposition entirely. Someone will eventually ask why a decision was made, and answering that the model suggested it does not survive that conversation. What works there is narrow: let the model read and draft, let ordinary code do the arithmetic and apply the rules, and keep a record showing what the model produced, what the rules did with it, and who approved the result.

Sometimes the answer is no

We have talked clients out of AI more than once.

If a task has a correct answer that a rule can compute, write the rule. A model that gets VAT right most of the time is worse than arithmetic that gets it right every time, and it costs more per call. If the input is a form with eight fields, the feature is a form with eight fields.

And if the output drops into a regulated record with nobody reviewing it, the question stops being whether the model is good enough. It becomes whether you can explain the decision afterwards to somebody entitled to ask.

What it costs to run

The bill is not fixed infrastructure. It moves with usage, and usage moves with choices made in the interface. An assistant that runs on every page load costs more than one behind a button. A summary regenerated on each visit costs more than one cached until the thread changes. A large model on a task a small one handles is money spent on nothing at all.

So usage is reported per feature, and the monthly figure becomes something agreed in advance rather than discovered on an invoice. Where a feature could run away with itself it gets a ceiling, and what happens when it is reached gets decided in advance too. A feature that degrades to a plain search box under load is a better outcome than one that quietly triples a bill.

Before any of it goes near a customer there is a set of real examples with known good answers, and every change runs against it. Fifty drawn from the actual inbox beat a thousand invented ones. This part is unglamorous, and it is the whole difference between a feature that improves and one that drifts. Without it a prompt change is a guess, and the only feedback loop left is a customer complaint. The set grows, too, because every wrong answer somebody reports becomes another example. That is the second reason the reporting route matters.

The first piece of work is usually a short one. We look at the questions arriving in your support inbox, or at a process you would hand to a new starter along with the documents they would need, and come back with a read: whether AI helps here, roughly what it costs to run, and where it will struggle.

Sometimes that read says no. It is a useful answer, and a much cheaper one than finding out after the budget is committed.