There's a pattern showing up across a lot of businesses right now. Someone opens an AI coding tool, Claude Code, ChatGPT, Codex, whatever's closest to hand, types out a version of "build me a system for X," and a few hours later has something that runs. It looks like progress. Often it is progress, in a narrow sense.
But there's a question that usually gets skipped: was building anything the right move in the first place?
Two things tend to happen when that question doesn't get asked. The first is that a tool already exists, off the shelf, cheaper and faster than anything custom, that does what's actually needed. Finding that out takes an afternoon. Building your own version of it takes weeks, and you're now responsible for maintaining software that a subscription would have handled.
The second is subtler, and more common: the thing being described as "the problem" is really a symptom of something else, a process problem, not a technical one. No amount of well-built software fixes a problem that isn't technical. It just gives the underlying issue a nicer interface to hide behind.
Three shapes this takes, in practice:
A school wants a fee-tracking system. Before any development, the actual process gets mapped out, and it turns out half the pain wasn't a software gap at all, it was three staff members with three different informal ways of recording the same thing. What ships is smaller than first asked for, and it holds up because it was scoped to what was really needed.
A retailer asks for "a system to manage inventory better" and gets exactly that, fast. Three months in, it's barely used. The real pain was two people with overlapping authority duplicating each other's reorders. The software works. It just isn't solving the problem that was costing them money.
A business builds an internal tool around a workflow described once, verbally, never tested against how the team actually works. It ships, technically correct, and immediately conflicts with three people's real jobs. Nobody wants to call the build wasted, so it gets bolted onto the real process instead of replacing it. A year later, the business is maintaining two systems of record that disagree with each other. Untangling that costs far more than the original build did.
None of this is an argument against AI coding tools. We use them ourselves, deliberately, including to build AI-powered features and products for clients when that's genuinely the right fit, not because it's trendy. A small team with a clear, well-scoped need can get something built in days that used to take months. The catch is that "well-understood requirement" part: AI tools are extremely good at building what you ask for, not at telling you whether you asked for the right thing.
That's what we'll unpack next: once something genuinely needs building, the benefits of building it fast with AI assistance come paired with downsides, and those two things don't just sit side by side. They interact, over the life of the product.
If you're weighing whether something in your business actually needs a custom build, or needs something else entirely, that's exactly the conversation we like to have before any code gets written.
Get in touch