Adding AI to your product without the hype

Where LLMs genuinely help — assistants, RAG search and automation — and how to integrate them safely.

AI has become a strategy in search of a problem. Somewhere between the demos and the funding announcements, "add AI" turned into a goal in itself — a box to tick rather than a job to be done. But a model is not a feature, and a chatbot is not a strategy. The useful question is never "how do we use AI?" It's "what is a real, specific problem our users have — and is a model genuinely the best tool for it?" Everything good starts there.

Start with the job, not the model. The best AI features are usually invisible: a search that finally understands what you meant, a form that fills itself in from a document, a support reply drafted before the agent has finished reading. Ask whether a competent human would find the result valuable. If the answer is no, a bigger model won't save it. If the answer is yes, you now have something worth building — and a clear way to tell whether it works.

Know where language models genuinely earn their place. They are excellent at a specific class of tasks: understanding messy human language, summarising and drafting, pulling structure out of unstructured text, and answering questions over a body of knowledge. Assistants that guide users through a complex product, retrieval-augmented search across your own documents, and automation that reads and routes incoming information are the cases where the technology reliably pays for itself.

And know where they don't. If a task is deterministic — a calculation, a lookup, a rule — then a query or a few lines of ordinary code will be faster, cheaper, and correct every single time. Using a language model there isn't innovative; it's expensive and fragile. Maturity in this space is mostly knowing when not to reach for the model.

Ground the model in your data. A model on its own knows a great deal about the world and nothing about your business. The value comes from connecting it to your content — your documents, your policies, your catalogue — and having it answer from that, with sources, rather than from memory. This is what turns an impressive-but-unreliable demo into something a business can actually trust.

Design for being wrong. Models are confident even when they shouldn't be, so the product — not the model — has to hold the line. That means guardrails on what it's allowed to do, a human in the loop wherever the stakes are real, graceful fallbacks when confidence is low, and always making it easy to see where an answer came from. A feature designed as if the model is always right will eventually embarrass you. One designed to fail safely will quietly earn trust.

Measure it like any other feature. "It feels smart" is not a metric. We evaluate AI features on real examples, track accuracy, latency, and cost per interaction, and watch whether people actually adopt them. And we take privacy seriously from the start — being deliberate about what data is sent where, and never treating a convenient integration as permission to be careless with someone's information.

Used well, AI doesn't announce itself. It shows up as a product that understands its users a little better, removes a little more friction, and quietly does work that used to take someone an afternoon. The goal was never to have AI. It was to build something people find useful — and to reach for the model only when it's genuinely the best way to get there.