Why the groundwork matters more than the clever bit
A few different jobs this month have all pointed at the same thing, even though on the surface they had nothing in common.
An AI agent, a website that wasn't ranking, an app build, a client's week disappearing into admin, a chatbot that wasn't working.
Different problems, same root cause. Somebody had skipped the unglamorous bit in favour of the part that felt more like progress.
The parts nobody wants to check
With SEO, the exciting bit is writing. New blog posts, better headings, keyword research. The laborious bit is checking whether the site actually loads quickly, whether there are duplicate pages fighting each other, whether the sitemap reflects what's actually live.
I've found basic technical issues on sites that had been live for years, simply because nobody had gone back and looked. Content still matters. It's just rarely the first thing worth checking when something's clearly wrong.
Building an app is similar. It's tempting to describe something loosely and refine it as you go, chatting back and forth until it feels right. Every correction gets carried into the next exchange, so the mess compounds rather than settles. Writing a proper brief first, treating it almost like a spec, and then batching corrections rather than trickling them in one at a time, is less satisfying in the moment but produces a cleaner result for less money. Front load the thinking. The build itself should be the boring, predictable part.
Building AI that knows its limits
The same pattern shows up in AI agents. Most demos are built around the agent getting things right, because that's what sells the idea. The useful question is what it does with the awkward case, the half formed enquiry, the customer who's clearly annoyed and just wants a person. An agent that's only ever been shown the tidy path will confidently give a wrong answer rather than admit it doesn't know, which is worse than looking unfinished. Spending time on the exit paths, not just the main flow, is the part that gets rushed because it isn't the interesting bit to build.
It's also why a chat interface isn't automatically the right shape for a process. A structured, step by step approach with a proper admin view can be less flashy and considerably more useful than a free flowing conversation, if the task genuinely needs specific information in a specific order.
Know where the time goes before automating
The same logic applies before you spend anything on automation at all. Ask how much of a working week actually goes on quotes, repeated questions and chasing information, rather than the work itself, and the answer is usually bigger than people expect. Worth working that out properly before assuming you know what to fix, or spending money automating the wrong thing.
None of this is complicated. It's just easy to skip in favour of the part that feels like moving forward.
