Does your product actually need AI?
Yehor Skorniakov
Head of Development at Alty
June 18, 2026
I get asked to add AI to products more often than I get asked whether they need it. Those are different questions, and the gap between them is where a lot of money disappears.
I'm not against AI. We build it into products where it holds up. But "we should add AI" has become the kind of decision that arrives already made, usually from a board meeting or a competitor's press release, and lands on an engineering team that knows it won't survive contact with production. So before anyone writes a line of it, here's what I'd actually check.
Is there a problem that AI is the best answer to?
Most features framed as "AI" are solving a problem that a simpler tool solves better. Search, ranking, recommendations, and basic automation. Half the time, the honest version of the request is "we want it to feel modern," and AI is just the nearest way to signal that, which is a lot to pay for a signal.
So the first question is plain: what specific thing gets better for the user, and is AI genuinely the best way to get it there? If the answer is a rules engine, a better search index, or fixing the onboarding flow you already have, do that. It'll ship faster, break less, and cost a fraction to run.
AI earns its place when the problem is genuinely hard to specify in rules. Language, messy, unstructured input, pattern recognition across data that no human could scan. If your problem isn't shaped like that, you're paying a premium for a worse fit.
Do you have the data, honestly?
This is where most AI plans quietly fall apart. A model is only as good as what you feed it, and "we have lots of data" rarely survives a real look. It's scattered across systems that don't talk to each other, it's inconsistent, it was never labelled for the thing you now want to predict, and in regulated environments, half of it you're not allowed to use the way you'd need to.
I've watched teams budget for the model and forget the real work is the data plumbing underneath it, which can run longer than the rest of the build combined. If your data isn't ready, the AI feature isn't a feature yet. It's a data project, and it should be cost as one.
Can you carry it after launch?
An AI feature isn't something you ship and walk away from. Models drift. Inputs change. What worked at launch degrades quietly, and someone has to notice, retrain, and redeploy. There's monitoring to build, edge cases to catch, and a cost-per-call that climbs with usage in a way a normal feature doesn't.
A test I'd run: imagine the feature is live and slightly wrong in a way no one catches for three months. In a regulated product, when the thing being slightly wrong is a customer's money or a compliance decision, what does that cost? If that answer worries you, the question was never whether the model is accurate enough today. It's whether you've built the operation to keep it accurate, and most teams cost the first and forget the second.
When the answer is no
Sometimes the honest read is that AI doesn't belong in this product yet. We've told clients that. The simpler build shipped sooner, cost less to run, and left the door open to add AI later, once there was a real problem for it to solve and the data to support it.
There are a lot of products out there that added AI to look current and now pay to maintain a feature nobody opens. You can't see that cost from the outside. The team carrying it knows exactly what it is.
The teams that get this right ask a smaller question than "should we add AI." They ask whether this product, with this data, in this regulated context, has a problem worth solving that way. Usually, the answer is yes in one place and no in a few others. Most of the work is telling those apart.
I've spent enough years shipping fintech products to have built AI that earned its keep, and to have talked teams out of AI that wouldn't have. The second call is harder to bill for and usually the more useful one.
Working out where AI fits in your product, or whether it fits at all? Let's talk.
