A good share of the “we need AI” conversations we have end up somewhere else entirely: with a process nobody ever wrote down, or two systems that don’t talk to each other, or a job that no single person owns. AI was the word the client arrived with. The thing causing them pain was usually more ordinary than that, and a lot cheaper to fix.
That isn’t a knock on anyone. “We need AI” is what the market has taught people to say when an operation feels slower or messier than it should. But if you spend on the headline instead of the cause, you get an expensive layer of cleverness sitting on top of a problem it can’t reach.
What the request usually means underneath
When we dig into one of these, the same handful of root causes come up:
- A manual process that was never defined. Three people do the same task three different ways, so the output is inconsistent and slow. The fix is agreeing and writing down the process, not predicting it with a model.
- Systems that don’t share data. Someone is the human glue, copying figures from one tool into another. The fix is an integration.
- No single source of truth. Everyone trusts a different spreadsheet. AI pointed at contradictory data just gives you confident contradictions.
- A job with no owner. Things fall through because nobody is clearly responsible, and software of any kind can’t assign accountability you haven’t decided on.
None of those need a model to solve. They need the unglamorous work of pinning down how the operation runs.
Why AI on a broken process makes things worse
Automation amplifies whatever it sits on. Put it on a clean, well-understood process and it removes drudgery. Put it on a messy one and it produces the mess faster, with a layer of plausible output that’s now harder to question because “the AI did it.” You’ve spent money to make a bad process more confident.
It’s the same reason a custom dashboard fixed nothing for us until we’d sorted the process behind it first. The tool was never the lever. The process was.
When AI is the answer
Sometimes it really is, and we’ll say so. Once a process is clear and the data is trustworthy, there are jobs where a model earns its place: reading and sorting unstructured text, drafting from a known template, triaging high volumes so a person only sees what matters. We build those, and they pay off, because by then they’re solving a defined problem rather than papering over an undefined one. That is what our AI development work involves, and it almost always starts with the process, not the model.
How to tell which one you’ve got
Before you brief anyone on AI, ask a plainer question. If you handed this task to a sharp new starter with clear instructions, could they do it well? If the honest answer is no, because the instructions don’t exist, you have a process problem, and that’s where the money should go first. If the answer is yes, but it would take them all week because the volume is crushing or the inputs are messy text, that is where AI starts to make sense.
Who this isn’t for
If you’ve already done the process work and you’re looking for a partner to build the model layer on top, you don’t need this argument and we can get straight to it. This is for the much larger group who are about to spend on AI to avoid a harder conversation about how the work is organised.
If you’re not sure which camp you’re in, that’s worth twenty minutes before it’s worth a budget. Tell us what you’re trying to fix and we’ll tell you honestly whether the answer is a model or a tidier process.
Written by
Alex
CEO
I’m a software developer and CEO of Digital Royalty, helping growing teams scale their SaaS platforms without losing quality, visibility, or control. I focus on building structured, maintainable systems with clear processes, reporting, and accountability. With over a decade of experience across agency and in-house roles, I specialise in delivering long-term, scalable solutions that support complex, evolving products.
