From the field, not the whiteboard.

Most AI project briefs contain three things: a description of what the business wants, a rough sense of the technology involved, and a lot of assumptions that nobody has written down. The build happens. The assumptions surface. The result was not quite what anyone actually needed. A good brief is the document that makes those assumptions explicit before anyone starts writing code. It is not a long document. It is not a technical specification (that comes later, once a developer has reviewed yo

Most AI projects don't fail because the technology doesn't work. They fail because nobody agreed on what it was supposed to do. The brief was vague. The scope kept shifting. The developer built what they understood, which was not quite what the client meant, which was not quite what the client's team actually needed. Six months later, something technically functional exists and nobody quite uses it. This is the most common failure mode in AI implementation. And it is almost entirely preventabl

Grapine's founder has been building AI systems for enterprise organisations since before most of the current conversation existed. Not in the sense of reading about it, advising on it, or building prototypes. In the sense of shipping production AI into large organisations and living with the consequences when it did and didn't work. That experience doesn't produce cynicism about the current moment. The capability jump of the last few years is real, genuinely significant in a way that previous w

When a business commissions an AI implementation, the number they focus on is the invoice. The cost of the build. The line item on the budget. That is the wrong number. The invoice tells you what you spent. It doesn't tell you what the implementation actually costs. And for a surprising number of AI projects, those two numbers differ significantly. What businesses count The cost of an AI implementation, as most finance teams track it, is the direct build cost. Developer time, tooling, API c

The first thing we do when we audit a business for AI opportunity isn't to talk about AI. We ask questions. Specific ones, in a specific order, designed to get past the self-diagnosis problem, the gap between what a business thinks its biggest AI opportunity is and where the real one actually lives. We've written before about why that gap exists. The short version: when you're inside a business, you see the output of problems, not their source. The most painful tasks aren't always the biggest

Every business we've audited has come in with a theory about where AI will save them the most time. Every single one has been surprised by what the data showed instead. Not because they were wrong to think AI could help. They were right about that. They were wrong about where. This is more common than people admit, and more expensive than people realise. Getting the diagnosis right before building anything is the difference between an AI investment that pays back in 30 days and one that costs

Before we automate anything, we sort every task in a business into one of three buckets. The bucket determines whether AI can help, what kind of help it gives, and whether the ROI is real or something that sounded good in a meeting. Most businesses skip this step. They see a demo, something impressive happens, and the question becomes: can we use this here? The better question is: what are we actually trying to do, and where does AI make that faster without making it worse? The answer is rarel