Cheap AI building is creating a big ball of mud

Funny how things come back around, isn’t it? Around the turn of the millennium every company had their own bespoke versions of everything. Website back-ends, CRMs, you name it. Then came the era of SaaS - offering to take all that ownership and maintenance hassle off your hands for an enterprise-level annual price tag.

And now, it seems, many companies are wanting to go back to those early days, thanks to agentic systems and building with AI, and cast off the five and six-figure bills in favour of fully owned and operated systems. Power to the people, right?

Well, maybe not. Looking at NN/g’s article earlier this month, ‘The New Big Ball of Mud: Why Agentic AI Systems Turn Fragile’, the reality is that while building is cheap, owning, operating and maintaining isn’t.

There’s been a lot of headlines recently about engineers recreating big legacy apps like Photoshop; tools like Claude Code and Codex being able to output seemingly comparable tools in no time, leading to a lot of ‘Is SaaS dead?’ pontification and yawnsome AI hype. But as anyone who has tried to build a product (myself included) will tell you: building is the easy bit.

The ‘big ball of mud’ idea was coined in a 1997 paper by Brian Foote and Joseph Yoder, and describes software that is hastily slapped together to meet an immediate need. Sure, it might seem useful at first, but then as more bugs get fixed, edge cases get addressed, new functionality gets requested, more and more layers of digital mud get piled on until you’re left with a monolith: an unmaintainable, unscalable piece of bloat.

This is exactly why SaaS became popular in the first place. Platforms like Workday, NetSuite, Salesforce - household names to many of us today - cornered the market in the early 2000s by offering one simple thing: a shift from large upfront CAPEX to predictable OPEX subscriptions.

Companies love reliability and certainty, especially in cashflow, so these platforms scaled rapidly; average estimates of early SaaS revenues show a 37% growth rate from 2000-2010. This was only spurred on further with the introduction of cloud computing in the 2010s and again with the COVID pandemic in 2020, changing the way many of us work day to day even six years on.

Predictably, costs for these platforms have exploded too. A previous role of mine underwent a Slack migration: a $100k annual bill plus a big upfront cost, not to mention the time of everyone to implement it, all to replace something (Teams) that they continued to use.

So it’s not surprising that so many are tempted by AI’s promises of ‘oneshotting’ your current pain point. Or, as the NN/g article also covers, ‘piecemeal growth’, which is using AI to build a small amendment to your workflow, and then another, then another, then another.

That abundance has a catch, though. When you’ve never built or designed software before, you likely have no concept of architecture, durability, scalability, security or all the other things that soon unravel, because of a poorly-thought-out solution to an immediate problem.

I’ve worked at a couple of companies now where the main back-end platform was put together, even in the pre-AI days, by engineers who thought they could ‘do UX’. And these platforms were a hulking mess, because their ownership was purely executional, not strategic. No thought had been given to how the platform should work, how it might grow, or where new features would live as and when they were conceived.

In one notable example, the team used both the in-house solution and HubSpot. The in-house platform was the main source of truth for customer data, but the UX was so bad the sales teams only used HubSpot, causing huge amounts of data drift and inconsistency. They tried to force the teams to use it, to no avail. Such is the power of a good experience.

Good information architecture has always been the unsung hero of projects like this, but even more so today. Proper multi-level navigational structure, consistent naming, tools based around the core JTBD… some might say this stuff has no place in a world where products and services can be shipped in mere hours; but without it we’re just applying the mud with a firehose.

So what’s the solution? As I’ve discussed before, the mindset of just ‘ship and learn’ for everything needs to die; just because you can build something, doesn’t mean you should, and even if you should, doesn’t mean you know the best way to do it. There are many tools you can use to ensure that you at least get off on the right foot with a software project - not least your AI tool itself.

Any time I make anything even remotely sizeable for Tilia I start off in plan mode in Claude - I would rather spend an hour going back and forth on the interrogation of an idea and its implementation, to make sure it’s feasible, viable, usable and will add value, than spend that time pinging half-baked PRs around.

If you’re working on new features, or even going 0 >1 on something, take the time to properly scrutinise it. Use plan modes to structure your thinking and red-team your ideas. Run a tree test, do a card sort, put a prototype in front of someone. See if your structure, your words, your logic make sense to someone with zero context.

That way, you won’t be flinging mud. You’ll be sculpting clay.