I have had roughly the same conversation six times this quarter. A founder arrives with an idea that is genuinely decent, and somewhere in the first ten minutes they say the line: “and then we add AI here.” There is usually nothing behind the line. AI integration has become the ingredient everyone wants and almost nobody has thought through. As a founder who also builds, I understand the pull completely. But I have watched enough projects stall on exactly this part that I want to write the pattern down, because it is where budgets quietly evaporate before anyone notices.
The pattern: AI as decoration, not as a feature
The most common mistake is not technical, it is a framing error. The founder pictures AI as a layer you add on top of a finished product, the same way you add a logo or a brand colour. They arrive with the screens drawn, the flow locked, and AI marked as a to-do at the bottom of the list. When we ask what that model actually needs to do, what data it consumes, what happens when it gets things wrong, and how we will know if it works, the answer is usually silence.
AI integration is not a decoration you hang on at the end. It is a product feature, with inputs, outputs, edge cases, and a cost per use. Treating it as an ornament means it gets designed last, tested worst, and budgeted cheapest, which is precisely the combination that guarantees trouble later.
Mistake one: confusing “using a model” with “building one”
Almost none of the projects that reach us need to train their own model. Most of them need to connect an existing model, from OpenAI, Anthropic, or whoever, to a specific problem and a specific set of data. These are two different worlds with completely different prices and timelines.
When a founder tells me they want “their own AI”, they are usually imagining months of work and a six-figure cost they do not need. And the other way round, when someone thinks it is “just an API call”, they are almost always underestimating the hard part, which is not the call itself but everything around it: preparing the context, controlling the output, handling errors, and measuring quality. The honest conversation starts by separating those two things before anyone talks about money.
Mistake two: ignoring what happens when the model is wrong
A language model gets things wrong. Not occasionally, but predictably: it invents facts, misreads questions, and gives confident answers that are simply incorrect. A serious product is designed around that from day one. Most of the briefs I receive do not mention failure anywhere, as if the AI were going to be right every time.
This is where a prototype separates from a demo, and a demo separates from a real product. The question is not “does it work when I type what I expect?”, it is “what does the user see when the model gets it wrong, and how much damage does that do?” In a recipe app, very little. In one that touches money, health, or personal data under UK GDPR and the ICO, a great deal. Designing an AI integration is mostly designing the behaviour for when the answer is bad.
Mistake three: not counting the cost per use
A normal feature is built once and its cost is roughly fixed. A feature with AI has a cost you pay every single time someone uses it, because each call to the model costs money. That is a business-model difference, not just an engineering one, and hardly anyone brings it thought through.
I have seen lovely ideas that do not survive their own numbers, where the cost of each model interaction ate the margin before the first paying customer arrived. It is worth doing that sum early, on the back of a napkin if you have to. If each active user costs more in AI calls than they pay you, you do not have a product problem, you have an arithmetic problem, and it is much better to find it in week one than in your funding round.
Why it keeps happening
I think it happens for two reasons. The first is noise. There is so much conversation about AI that not having it feels like falling behind, so it goes into the brief out of fear rather than function. The second is that AI demonstrates brilliantly in a thirty-second video and badly in the boring details, which is exactly where a real product lives. The gap between the demo and the product is enormous, and that gap gets paid in pounds.
I am not writing this to put anyone off. Well-built AI genuinely changes products, and some of the work I am proudest of leans on it hard. I am writing it because the part that creates the advantage is the part almost nobody plans for.
What works instead: AI integration as a first-class feature
What works is treating AI integration as a first-class feature, not the last line of the list. In practice that means three concrete things before anyone writes a line of code.
First, write in one sentence what the model does and how we will know it is doing it well. If it does not fit in a sentence, it is not thought through yet. Second, draw the failure path with the same care as the success path: what the user sees, what they can correct, and when a human steps in. Third, do the cost-per-use sum with real numbers, even rough ones, so you know whether the idea holds up at scale.
When a founder arrives with those three answers, the whole conversation changes. It stops being “we add AI” and becomes a product with a clear function, a plan for when it fails, and an economy that adds up. If you are at that point and want an honest read on whether your AI integration stands up, tell us about the project and we will look at it with you, no hype.
If you are still working out the numbers underneath all this, it is worth reading what an MVP really costs in the UK in 2026 and the five-customer approach to user research. Most of the mistakes in this piece are avoided by a good conversation before you build, not by more technology.
.webp)
.webp)
