Someone on your board has asked what your AI strategy is. A competitor has shipped a sparkly button. Your investors want to hear about it. So the question arrives as pressure rather than as a product decision, which is exactly how bad features get built.
Two questions decide whether adding AI features to your product is worth it. Does the feature use your data or context in a way a general assistant cannot, and can you afford its cost per request at the volume you are hoping for? A feature that fails either is not a feature, it is a demonstration.
The first question: what do you know that it does not?
Your customers already have access to a general assistant. It is free or nearly free, it is very good, and it is one tab away. So anything you build that they could get by pasting their question into that tab is not a feature, it is a worse version of something they already have, inside your product, that you now pay for.
The features that survive that test all share a shape: they use something only your product holds.
- Their own data in your system. Summarising this customer's history, drafting a reply in the context of this ticket, spotting the anomaly in this month's figures. A general assistant cannot see any of it.
- The action, not just the answer. Not telling them what to do, doing it. Creating the record, scheduling the job, applying the change. The value is the completed task rather than the text.
- Your accumulated knowledge. Rules, precedents, documentation and history built up over years. Not general knowledge with your logo on it.
- The place it happens. Inside the workflow, at the moment of need, with no copying and pasting. Convenience is a genuine feature and the only one on this list that is purely about placement.
If you cannot finish the sentence our version is better because it can see..., you do not have a feature yet. That is not a reason never to build one, it is a reason to improve the core product first.
The second question: what does it cost per use?
This is the one that surprises product teams, because it inverts the economics they are used to.
Conventional software has near-zero marginal cost: one more user costs you almost nothing. A feature calling a language model does not work that way. Every use has a real cost, driven by how much text goes in and comes out, and it scales with usage rather than with revenue. A feature that is delightful and heavily used can lose money on every request.
- Work out the cost of one use before building, using the actual amount of context you would send. Not a guess.
- Multiply by realistic usage per customer per month. Be pessimistic, which here means assume they love it.
- Compare with what that customer pays you. If a heavy user costs more than their subscription, you have designed a business problem rather than a feature.
- Decide the lever now, not later: a usage limit, a higher tier, a smaller model for the routine cases, or caching the repeated ones. Deciding this after launch means either withdrawing something popular or absorbing a loss.
The good news is that the levers are real and effective. Most requests do not need your most capable model, repeated questions can be cached, and the amount of context sent is usually far more than necessary once someone looks. Costs also fall over time, which is a genuine tailwind. But the arithmetic has to be done before the build, because it changes what you build.
Why thin wrappers fail
A wrapper is a feature that passes the user's text to a general model and shows the reply. It demonstrates well, ships quickly, and is the most common thing built in response to board pressure.
It fails for four reasons. It is trivially replicable, so it is not a moat. Your customer can get the same thing free in another tab, so it is not a reason to choose you. It costs you money per use for something that generates none. And when it is wrong, which it will be, the reputational cost lands on your product rather than on the model provider.
The version that works is almost always narrower and less impressive in a demo: one specific job, done inside the workflow, using data only you hold.
Which AI features to add to your product, in order
| Feature | Why it works | Watch for |
|---|---|---|
| Draft, do not send | The user gets a head start and stays in control. Highest acceptance, lowest risk, and it works even when the output is imperfect. | Nothing much. This is the safest place to start and the hardest to regret. |
| Summarise what is already there | Long threads, histories, documents. The value is entirely in your data, so the wrapper objection does not apply. | Accuracy on the details people act on. Summaries that quietly drop the important line are worse than none. |
| Search that understands the question | Finding the right thing in your customer's own content is a genuine improvement over keyword search. | It must cite where the answer came from, or nobody trusts it twice. |
| Extract structure from mess | Turning an email, a photograph or a document into fields in your system. Unglamorous and consistently valuable. | The failure mode is silent and wrong, so it needs a review step for anything consequential. |
| Do the action | The highest value and the highest risk, because now it changes data rather than describing it. | Confirmation, an undo, and an audit trail. Not optional. |
| Open-ended chat | The one everybody builds first. | Usually the wrapper. Build it last, if at all, once you know from the others what people actually ask. |
The order is close to the inverse of what most roadmaps propose, which is worth noticing.
How customers will judge it
Worth planning for, because the reaction to an AI feature follows a pattern that catches teams out.
- The first wrong answer costs more than the first ten right ones earn. People extend a single visible error across everything else the feature does, and reasonably, because they cannot tell which other outputs share the flaw. Design so the first impression is a category you are confident about.
- Nobody is impressed that it uses AI. That novelty is gone. They will judge it as they judge any feature: did it save me time, was it right, did I have to check it. Marketing the technology rather than the outcome now reads as thin.
- Opt-in beats surprise. A feature that quietly changes what happens to someone's data or content generates a much worse reaction than the same feature offered. This is a trust question rather than a technical one.
- Some customers will object on principle, particularly about their content being processed. Have a plain answer about what is sent where, what is retained and whether they can decline. Not having one turns a fair question into a story.
- Usage tells you more than feedback. People are polite about AI features in surveys and simply stop using the ones that do not help. Watch the second-week usage rather than the launch-week enthusiasm.
The practical consequence is to launch narrow and to a subset, watch the second week, and expand only what people came back to. That is ordinary product discipline, and it gets abandoned surprisingly often for these features because the pressure to ship something visible is coming from outside the product team.
What it costs to build
| Scope | Build | Ongoing |
|---|---|---|
| One focused feature, grounded in your data | $15,000 to $45,000 | Per-request cost, plus someone watching quality |
| Several features, with evaluation and monitoring | $50,000 to $150,000 | The above, plus the evaluation suite you must maintain |
| A capability the product is built around | $150,000 and up | A permanent part of engineering, not a project |
Illustrative ranges from the kind of work we quote, not a price list. The line most often missing from a plan is evaluation: without a way to tell whether a change made answers better or worse, you cannot safely improve the feature after launch.
That last point deserves emphasis. These features cannot be tested the way ordinary software is, because there is no single correct output. You need a set of real examples with agreed good answers, run automatically, so a change can be judged. Teams that skip it ship a feature and then dare not touch it. Our custom AI work treats that as part of the build, and can you trust what an AI assistant tells your customers covers designing for the wrong answers.
Build, buy the model, or buy the whole feature
A choice that gets skipped, because the assumption is that adding AI means calling a model yourself. There are three routes and they suit different situations.
- Call a hosted model. The usual route. Fast to start, no infrastructure, and you pay per request. Best for almost everyone beginning, and the thing to weigh is that your costs are set by someone else and can change.
- Buy a feature from a specialist. For common jobs such as document extraction, transcription or search, mature products exist that are better than what you would build and cheaper than the engineering time. Genuinely worth checking before writing anything, and rarely checked.
- Run a smaller model yourself. Sensible when volume is high and the task is narrow and repetitive, since a small model doing one job well can cost a fraction per request. It buys predictable cost and privacy control, and it costs you the engineering to run it.
Most products should start with the first, check the second before building anything routine, and consider the third only when the per-request arithmetic has become the problem. Moving between them later is normal and much easier if the feature was built with the model behind an interface rather than woven through the product.
Not for you if
One test to apply to any AI feature on your roadmap: could a customer get the same result by pasting into a free assistant? If yes, you are about to pay per request for something they already have. If no, say precisely why not, and that sentence is your product requirement.