Auto Alpha Advisory
Gartner predicts that at least 30% of generative AI projects will be abandoned after proof-of-concept by the end of 2025 — citing poor data quality, inadequate risk controls, escalating costs, and unclear business value. RAND's root-cause study puts it more bluntly: “By some estimates, more than 80 percent of AI projects fail — twice the rate of failure for information technology projects that do not involve AI.” And the direction of travel is wrong — S&P Global's 2025 survey found the share of companies abandoning most of their AI initiatives before production jumped from 17% to 42% in a single year. Those numbers track with what I see in the South African market . The pilot ran. Something got demo'd. Then six months passed and nobody can quite explain why the system isn't actually running anything in production.
This isn't a technology problem. The technology works. It's a delivery problem — and the patterns repeat in nearly every stalled engagement I look at.
Here are the four most common ones, and the model I use to avoid them.
1. Buying tools instead of buying outcomes
Most AI engagements start the wrong way. A founder reads about an AI tool, asks for a demo, signs a SaaS contract, and then discovers — six weeks later — that the tool doesn't actually fit how their business works. They now own a subscription. They don't own a system.
The pattern:
"We bought {SaaS X}. We have an AI now."
What they actually have is a tool with a generic config that ignores their data, their workflows, and their stack. The vendor's incentive is to keep them paying. The vendor's incentive is not to make sure their leads, reports, or customer ops actually run end-to-end.
This is now measured, not anecdotal. MIT's NANDA initiative found in 2025 that roughly 95% of enterprise generative-AI pilots deliver no measurable P&L impact. Lead author Aditya Challapally's diagnosis is the pattern above, verbatim: “Generic tools like ChatGPT excel for individuals because of their flexibility, but they stall in enterprise use since they don't learn from or adapt to workflows.”
The fix is to invert the question. Don't ask "what tool should we buy?" Ask "what outcome are we trying to get to, and what's the smallest piece of system that achieves it?" The answer is almost always: a custom integration that wires the tools they already have, plus a thin layer of LLM logic where it's actually load-bearing. That answer only works if whoever gives it can also build it, which is why an AI consultant who can't write code is selling you opinions.
This is also why the automations I build aren't a subscription to my software. Every system runs in the client's own accounts. They own the keys, the code and the data from the day it's handed over.
2. The retainer with no deliverable
The second pattern is closely related. An agency proposes a monthly retainer — R30,000–R80,000 a month — to "implement AI" with no fixed deliverable. The client pays for activity: meetings, "discovery sessions," roadmap docs, slack messages.
After three months they have a thick deck and no production system.
The problem isn't the monthly fee. It's paying for activity instead of output. On a build, that moves the risk from the supplier, who should have to ship to get paid, to the buyer, who pays whether anything ships or not. That's the wrong way round.
The fix for a build is a fixed price at every stage, with a clean exit at every gate. The client should be able to stop after any stage and still have something useful. If a supplier is confident in the scope, they can quote it. If they aren't, they need more discovery, not a monthly fee.
A monthly fee earns its place once there's something to run, and only when each month has a defined output. When I sell a monthly advisory retainer, the deliverable is a written report every month (the three-layer report set out on the services page), not a calendar of meetings. If a supplier can't tell you what you'll receive each month, you're paying for activity.
3. No exit point
Even when the work is fixed-price, most engagements have no clean way to stop. The agency builds something. It almost works. Then it needs "phase 2." Then "phase 3." The client can't fire them because the half-built system is stuck on the agency's infrastructure, behind their accounts, with their commit history.
This is a hostage situation, dressed up as professional services.
The fix is documentation, infrastructure ownership, and a methodology gate at every release. Every stage of the work must hand back something the client could maintain or extend without me, even if they choose not to. If I get hit by a bus on Friday, the client should be able to bring in another developer on Monday and have them productive within an afternoon.
That sounds obvious. Almost no agency actually delivers it, because doing so makes them easier to replace. I do it because the alternative is unethical.
4. Scope without ROI
The fourth pattern is the most subtle, and the most expensive. The team agrees on a scope. The scope sounds reasonable. They build it. It works. It doesn't matter.
The system was scoped before anyone measured what would actually pay back. So the team built a slick lead-routing automation for a company whose real bottleneck was inventory replenishment. Or a chatbot for a B2B firm whose customers prefer email. Or a knowledge base for a five-person team that already knows everything by heart.
The fix is to start with measurement, not scope. Before building anything, identify where time, money, or revenue is leaking. Then sort by ROI. Then build the top one. Then measure again.
The research points the same way. BCG surveyed 1,000 executives across 59 countries for Where's the Value in AI? and found the companies actually capturing value pursue "only about half as many opportunities as their less advanced peers" while scaling more than twice as many. As BCG's Amanda Luther put it: "Three-quarters of companies have yet to unlock value from AI. Without decisive action, they risk falling significantly behind." Fewer bets, better chosen, measured before they start.
This is the most CA-shaped intervention I make. As a Chartered Accountant, my training is to count costs and trace cash flow. Most agencies have product managers who are excellent at scoping; they're less excellent at saying "this scope is wrong, we should be building a different thing." That's where having an operator with a financial background pays back fastest.
How I structure the work
I've productised this into a staged path, with a gate between each stage. The client can stop after any of them.
01 — Map (free, 90 minutes). I map how the business works today and find the automations that would pay back fastest, or say plainly that automation isn't worth it yet. The client leaves with an honest go or no-go. If they take that to another team, that's fine: they're better off than they were before the session.
02 — Pilot (fixed price). One automation against the highest-ROI target, built and proven on the client's own data, in their own accounts, behind a human gate. It has to reach 75% accuracy to advance. If the pilot doesn't earn its keep, the engagement ends here, with no obligation and no further spend.
03 — Ship (fixed price). If the pilot worked, I build the production system: monitoring, error handling, a POPIA review and a documented handover. The repo and the credentials are the client's. It ships at 85% accuracy, and runs unsupervised only once it passes 90%.
04 — Run (optional, monthly). Monitoring and tuning after Ship, and only once the system has earned it.
The point of this structure isn't to be clever. It's to remove the four failure modes one at a time. Tool-buying becomes outcome-buying because the work starts with measurement. Paying for activity goes away because every build stage has a fixed price. The hostage problem goes away because the client owns the infrastructure from day one. And scope-without-ROI goes away because nothing moves past the Map without a measurable target.
What this looks like in practice
An illustration, not a client story: picture a Cape Town hospitality group that asks for "AI for their booking system". That's the buying-tools framing. A Map session might find that the target that pays back fastest is somewhere else entirely: supplier invoices, say, with two staff spending half their week keying them in from email and a paper diary.
The pilot for that is small. An automation picks up supplier invoices from the inbox, extracts the line items with a vision model, and writes them into the accounting system with a flag for a person to check. If it takes the work from 20 hours a week to two, it pays for itself quickly.
The group never buys a SaaS tool or gives up its data.
That's the model. I didn't invent it, but in a market where most AI engagements still end with a slide deck and an unrenewed subscription, applying it consistently is most of the value.
Read next: What Building a 15-Module AI Due Diligence Engine Taught Me About Production Agents — the engineering side of the same argument: what the patterns above look like in code, with a worked example from one of my own builds.
If you've already paid for an AI tool and aren't sure what you got, or you're weighing an engagement and want a sanity check on the scope, start with the Map: a free 90-minute session that ends in an honest go or no-go, whoever you build with.