Building AI features that earn their cost
Every product roadmap now has AI on it somewhere. Most of those features will not survive contact with a budget review, because they were added to keep up rather than to solve something. The ones that survive tend to share a pattern, and it is worth knowing what it is before you commit a quarter of engineering to the topic.
This article is about that pattern: where machine intelligence genuinely pays for itself inside a product, when to buy it rather than build it, and how to scope the work so the cost stays proportional to the return.
What counts as an AI feature
It helps to separate two things that get called the same name. There are dedicated AI tools, where the model is the product, and there are ordinary products that use models quietly in the background to do a specific job better. Almost everything a normal company should build is the second kind.
That distinction matters commercially. Nobody chooses your product because it "uses AI". They choose it because the search finds the right thing, the support answer arrives in seconds, or the forecast is close enough to plan around. The model is plumbing, and plumbing is judged by whether the water arrives.
Where it actually pays
Personalization
Recommendation is the oldest commercially proven use, and it still works. A model that reads real behavior rather than a category tag surfaces what a customer is likely to want next, which shows up directly in conversion and repeat purchase. The requirement is data volume: with a few hundred users a month, hand-written rules will beat a model and cost nothing to run.
Support automation
Modern language models handle open-ended questions rather than the scripted trees that made older chatbots infuriating. Connected to your own documentation and order data, they resolve a meaningful share of routine contacts without a human. The value is not headcount reduction, it is that answers arrive at two in the morning, and your team gets the questions that actually need judgment.
Analysis and forecasting
Finding patterns across large volumes of operational data, predicting demand, flagging anomalies before they become incidents. This is the least visible use and often the most valuable, because it improves decisions that are made repeatedly.
All three share a shape: a repetitive judgment, made many times a day, where being right slightly more often compounds. If your candidate feature does not look like that, be suspicious of it.
Buy, call, or build
There are three levels, and the cost difference between them is enormous.
Use an existing tool. For internal productivity work, a subscription is the whole answer. No project required.
Call a model through an API. This is the right answer for most product features. You combine a general model with your own data and your own interface, and you get most of the value for a fraction of the cost.
Train something of your own. Justified when your data is genuinely unique, the task is specific enough that general models do it badly, and the result is central to your competitive position. Rare, and expensive when it is not warranted.
The pragmatic default is the middle option. It also keeps you free to switch models as the field moves, which it does roughly every quarter, provided the integration is designed with that in mind. That design work is ordinary custom software work, not research.
How to scope it without burning the budget
Start from the metric, not the technology. Name the number the feature is supposed to move: tickets resolved without a human, conversion on recommended items, forecast error, hours saved per week. If nobody can name it, the feature is a demo.
Then keep three things in view:
Running cost. Model usage is billed per request, so unlike most software it costs more as it succeeds. Measure cost per successful outcome rather than per call, and set a ceiling before launch.
Data and privacy. Decide up front what leaves your systems, where it is processed and how long it is retained. Under GDPR that decision is not optional, and retrofitting it after a review is the expensive route.
The failure mode. Models are confidently wrong sometimes. Design what happens then: a human handover, a visible confidence signal, a way for the user to correct it. Products that skip this lose trust faster than they gained it.
The same discipline that keeps an ordinary product honest applies here, which is why we treat an AI feature like any other bet and test it before building it, exactly as in validating an app idea.
The interface is most of the product
A model's output is raw material. Whether people get value from it depends on how it is presented: what the user is asked for, how results are shown, how corrections are made. In practice we spend more design time on an AI feature than on a conventional one, because there is no established pattern the user already knows.
That is UX and UI work in the ordinary sense, and it is where most of the difference between an impressive demo and a used feature is decided.
When to skip it
Skip it when a rule would do the job. Skip it when you do not have the data volume to beat a rule. Skip it when the failure cost is high and the oversight design is not in place. And skip it when the honest reason for the feature is that a competitor announced one, because that reason will not survive the first invoice.
There is no shortage of genuinely useful applications, but the useful ones start from a problem you can already describe in a sentence without the word AI in it. If you have one of those, tell us what it is and we will tell you whether it needs a model or a better query.
Frequently asked questions
Do we need to train our own model?
Almost never. For most business problems, calling an existing model through an API and feeding it your own data gets you most of the value at a fraction of the cost. Training becomes worth discussing only when your data is genuinely unique and central to the product.
What does an AI feature cost to run?
Model usage is billed per request, so cost scales with usage rather than sitting in the build. Budget for it as an operating line and measure cost per successful outcome, not per call, otherwise the number is meaningless.
Where does AI create the most value in a product?
Personalization, support automation and forecasting. All three share a pattern: a repetitive judgment made many times a day, where being right slightly more often compounds into real money.
What about our data and privacy?
Decide before you build what data leaves your systems, where it is processed and how long it is kept. Under GDPR this is not optional, and it is far cheaper to design for than to retrofit after a review.
How do we know if an AI feature is working?
Define the business metric before the build: support tickets resolved without a human, conversion on recommended items, forecast error. If a feature cannot be tied to a number like that, it is a demo, not a product decision.