Why most AI features fail after the demo
The demo is built by the person who knows exactly what to type. The product is used by someone who does not. That single gap accounts for most AI feature failures, and it is a product problem rather than a model problem.
There is a second, subtler failure. Traditional software fails loudly — a 500 error, a blank screen, something obviously broken. AI features fail quietly and confidently. The output looks right, reads fluently and is wrong. Users cannot tell, so they either stop trusting the feature entirely or, worse, they trust it and act on it.
Designing around that means accepting fallibility in the interface itself: showing sources, exposing confidence, making the correction path faster than the generation path, and defaulting to a human handoff whenever the stakes exceed the model's reliability. Products that do this feel trustworthy even when the model is imperfect. Products that hide it feel unreliable even when the model is good.
Evaluation is the product spec
If you cannot write down fifty real examples with the behaviour you would consider correct, you have not specified the feature. This is the single most useful discipline in AI product work and the one most consistently skipped, because it is slow and unglamorous and there is a demo to get out.
A working eval set has three parts: the happy path examples that must always work; the edge cases that reveal whether the system understands the domain; and the adversarial cases where the correct behaviour is to refuse, escalate or say it does not know. That third category is where most of the commercial risk lives.
Once the eval set exists, everything downstream gets easier. Model selection becomes a measurement instead of an argument. Prompt changes get tested instead of debated. And when a provider silently updates a model — which happens — you find out from a score drop rather than from a customer.
The unit economics nobody models until it hurts
Traditional SaaS has near-zero marginal cost per user. AI features do not. Every action has a token cost, and if a heavy user triggers forty generations a day on a frontier model, a £30-a-month subscription can go gross-margin negative without anyone noticing until the quarterly review.
The work here is unremarkable but it has to be done: cost per action measured in production, cost per user modelled at the ninetieth percentile rather than the average, and pricing designed with that in mind — usage tiers, fair-use limits, or a higher price point defended by the value delivered.
The engineering lever is model routing. Most requests do not need the most capable model. A cheap model handling the easy majority, with escalation to a stronger model when confidence is low, routinely cuts inference cost by half or more without a measurable quality difference on the eval set. That decision is a product decision, because the thresholds encode a trade-off between cost and user experience.
- —Measure cost per action in production, not from provider pricing pages.
- —Model the ninetieth-percentile user, not the average one.
- —Route cheap models first and escalate on low confidence.
- —Cache aggressively — a surprising share of requests are near-duplicates.
- —Set fair-use limits before launch; retrofitting them annoys your best customers.
Choosing between prompting, RAG and fine-tuning
The decision is simpler than the discourse suggests. If the model lacks knowledge, that is a retrieval problem — give it the right context at request time. If the model lacks a behaviour, format or tone, that is a prompting problem first and a fine-tuning problem only when prompting has demonstrably plateaued against the eval set.
Fine-tuning is worth it when you have a narrow, repetitive task, a few thousand good examples, and a cost or latency requirement that a smaller tuned model can meet where a large general model cannot. That is a real set of circumstances, but it is a much smaller set than the number of teams currently planning to fine-tune.
The practical sequence is always the same: prompt, measure, add retrieval, measure, then consider fine-tuning. Teams that skip to the end spend three months and a lot of money to discover that their retrieval was the weak link all along.