Integrating AI Into a Product Without Falling for the Hype
AI in a product requires careful thought. My criteria for deciding when (and when not) to integrate AI.
"We're going to add AI." I've heard this line on client projects and told it to myself. The trap is starting from the technology instead of the problem. Here's how I decide whether or not to integrate AI into my products.
Why I almost made a mess of things
When I first started thinking about AI in Coachy (my strength-training tracking app, currently in development), I did what everyone does: I listed every possible AI feature. Session analysis, program generation, automated motivation, auto-completion... Within two hours I had a list of 15 ideas.
The problem was that half of them didn't solve anything concrete. It was AI for the sake of putting "AI" on the product page.
On freelance projects, I saw the exact same reflex on the client side. Chatbots built in 3 weeks that nobody used. "AI-powered" features that added nothing to the existing workflow. Impressive demos in meetings that crumbled in production. The Gartner Hype Cycle describes this phase well -- many teams are still stuck in it.
The right filter: problem first
The turning point was flipping the question. Instead of "where can I put AI?", ask "what problem can't my users solve on their own?"
For Coachy, the real problem is data analysis. You accumulate hundreds of sessions, thousands of sets. How do you spot progression patterns? How do you detect a plateau? A human coach would do this naturally -- but they cost 50 euros an hour.
AI becomes relevant when it automates real expertise at scale. The model behind it can change -- and it will. What matters is that the user problem stays the same.
AI must solve a specific business problem. If you can remove the AI from your app without the user noticing, your integration is missing the mark.
Integrations that work (and those that don't)
What works
AI on structured data with a bounded context. Clear data (exercises, weights, sets), a bounded domain (sports coaching), actionable output (precise recommendations). The model has enough context to be useful, and the user accepts a margin of error -- an inaccurate coaching recommendation doesn't carry the same consequences as a medical mistake.
Invisible AI. Nielsen Norman Group puts it well: the best AI integrations are the ones the user doesn't even perceive as "AI." They see the benefit without thinking about the technology behind it. Auto-tagging of photos, anomaly detection, contextual suggestions -- the AI runs in the background and the user sees the result.
On-device AI. Apple Intelligence and Foundation Models make it possible to run models directly on the device. Privacy preserved, zero latency, no API cost. For Inner Gallery, I'm considering on-device object recognition down the road -- auto-tagging without photos ever leaving the iPhone. This type of integration would make real sense.
What doesn't work
The generic chatbot. "Hi! I'm your AI assistant, how can I help you?" The user wants an answer to their problem. They don't want to chat.
Content generation without context. The AI produces plausible but generic output. A training program generated without knowing the user's body type, history, and constraints is just noise.
AI as a marketing feature. "We're integrating AI to raise funding." Impressive demo, unusable product, exhausted engineering team. Seen it on a client project.
Artificial motivation. "Way to go champ, you're the best!" It's cringe. Users detect the fake in one second.
My decision criteria
Before integrating AI into a product, I ask myself 4 questions:
- What concrete problem does it solve? If the answer is vague, it's a no.
- Will the user accept errors? AI makes mistakes. That's fine for coaching or suggestions. It's unacceptable for accounting or security.
- Do I have quality data? AI without structured data is astrology.
- Can I measure the impact? Adoption, retention, satisfaction. If you can't measure it, you can't iterate.
Don't get attached to a model
An important point many developers forget: the model is an implementation detail. Models evolve every 6 months. The one you use today may be obsolete in a year.
Your product architecture must allow swapping models without rebuilding everything. AI layer abstraction, versioned prompts, clean interface between your business logic and the model.
If your product is built around a specific model, you're just as dependent as you would be on a SaaS that changes its pricing -- the same trap as with Webflow.
The user problem stays the same. The technology changes every 6 months. Build your product around the former.
Also worth reading:
- Event Sourcing in a Mobile App: Lessons Learned
- Build vs Buy: When to Build, When to Purchase
- Building Products on the Side of a Freelance Career