By the end of one week at a single company I'd been shown a strategy, an audit of the strategy, a strategy for actioning the audit, a prototype to explore the strategy, an audit of an existing CRM, a proposal for a new CRM to replace the one due to be audited again, a prototype of a dashboard to sit on top of whichever CRM won, a plan for an internal tool to feed it, and an audit of why the last internal tool never got finished. None of it was bad work. Most of it was good, and all of it was quick.
The company didn't have a shortage of thinking. It had a growing pile of it. What it was short of was anyone actually finishing anything.
It made starting almost free. What it didn't touch, not by a minute, is the cost of finishing.
This is the thing AI quietly changed, and it's easy to miss because the surface looks like pure gain. It made starting almost free. A strategy that used to be a fortnight is an afternoon. An audit is a prompt. A first draft of a tool arrives before lunch. What it didn't touch, not by a minute, is the cost of finishing. Building the tool for real. Cleaning the data. Making the decision the strategy implies and then living with it.
So each thing on the pile is a promise nobody has kept yet. A tool that needs developing. A direction someone has to choose and then own. AI hands these over faster than any team can keep up with them.
The tool will never warn you that you've overdone it. It will happily generate the strategy that sits on top of the strategy without any sense that the last three are still waiting to be actioned, and it can't hold that against you, because the goal is the one thing that never leaves the room with you. Ask it for another audit and you'll get a good one, and you'll feel productive while you do it, and that feeling is the whole trouble: it's the feeling of starting something, which from the inside is almost impossible to tell apart from the feeling of getting something done, even though they are not remotely the same.
You can see the over-indulgence up close in the small stuff. Someone shared some Python meant to turn a JSON file into a Word document. It didn't work, and they knew it. The worrying part wasn't that it was broken. It was that it ignored the standards we use and leaned on none of the tools we already have for exactly this job, and it was being carried around as though it were most of the way there. Quick to produce, nowhere near done. Another unfulfilled promise, and a bit of disappointment to go with it.
That's a small, cheap version of the mistake. The same reflex, reaching for something new when the thing you already have would do, can play out in a lot of places, and it matters far more once real money is involved.

An old, tired CRM. Or so everyone felt. Someone asked the AI to weigh up the problems with it, and the answer that came back argued for a new one, because the old one had been described to it as not working and broken (the CRM being the system a business uses to keep track of its customers and deals). The analysis was sound. It was also answering the wrong question, because a symptom isn't a problem, and the AI had only been shown the symptom. It didn't know the data was a mess, or that two teams recorded the same thing in different ways, or that nobody had owned the process in a year. It can't know. It works on the context you hand it, and the context it had been handed stopped at the surface.
The problem sat under the hood, in the joined-up knowledge of the people who actually run the thing, and no one had looked there. So the recommendation was to buy a new car when the driver just needed to move the seat forward. A new CRM would have carried the bad data and the bad habits across intact and shown the same problems by Wednesday. New always looks better than the workhorse in the corner. It's sexier, and AI makes the sexy option cheaper to reach for, because it hands you a business case that looks finished in an afternoon.
The expensive part, fixing the data and the habits, doesn't get cheaper because you generated the pitch faster. If anything the answer is to go slower, not faster, because the thing that was ever going to be hard is finishing, and finishing rewards attention, not speed.
None of this is an argument against the speed at the start. The speed is real and worth having. But notice where it stops. AI can dream, draft, audit, and propose all day. It cannot deliver a single one of them. That part still needs people: their time, their money, and someone willing to choose this and drop that. So the freer it dreams, the wider the gap between what's been imagined and what anyone actually has the hands to build.
Which is why we keep coming back to the same unglamorous discipline: a foundation sprint. Before anyone builds, you sit with the people who feel the pain and work out what it actually is, where it starts, and what a fix would have to change to count. It's the same instinct as a design sprint, testing a thing small and cheap before you commit to it, except pointed one step earlier, at the question rather than the answer. It's slower at the front and far faster overall, because it stops you delivering the wrong thing beautifully.
That's how the CRM went. We didn't rush to replace it, and we didn't rule it out either. The goal was to get the underlying data and the human processes around it solid first, because they were the real problem, and while we did that, to squeeze everything we could out of what they already owned. Sort the cheap things. Fix the worst of the bad data with a small back-fill. Add a lead scoring and enrichment step on top, built from tools the company already had. Then see whether the old system, given a fair chance, could actually do the job.
A symptom isn't a problem, and the AI had only been shown the symptom.
That leaves them in a good spot either way. If it turns out they do need a new CRM, the data and the process are clean and they're ready to move to one properly. If they don't, they've saved the best part of a hundred thousand pounds a year. The question was never whether they needed a new CRM. It was whether anyone had looked properly at the old one first.
The dreaming was never the hard part. Committing to something and delivering something that results in the change you want is, and that's the bit no tool will do for you.
If your own week looks like this
Maybe you've got your own pile: a handful of AI-generated starts, all reasonable, none of them finished, and a quiet sense that you should be further along than you are. It's a good problem to have, as long as you don't keep adding to it. Before you commission the next strategy or greenlight the shiny new tool, four questions will tell you whether you're about to finish something or just start another thing. This is roughly how we'd walk through it, and if you'd rather do it out loud, you can always talk it through with us.
- 01
Find
The real pain, not the symptom the pile is fixing. Sit with the people who feel it and work out where it actually starts.
- 02
Prioritise
The one thing worth finishing, chosen by what would change if it were done, not by which idea is newest.
- 03
Challenge
The idea, in front of whoever runs the thing day to day. The AI only knows the context it was handed, and the problem usually lives under the hood.
- 04
Define
What "done" means for this one item, and what it needs to get there: who, how long, and what they stop doing to make room.
Written by
James Dodd
Founder of moralai.co. A design led problem solver, with a photojournalism background, who has spent the last decade building software, brands and products for small businesses and the third sector.
If this got you thinking, let's talk.
A short call, no prep, no sales deck. Bring a question, a half-formed idea, or just your thoughts, and we'll help you find what actually works, AI or not.