AI Is Making Bad Software Decisions Look Cheap

I took over development of my own software company using AI. At another business, where we actually have an engineering team, I decided we should pay somebody else for the software.

The second decision took more discipline.

At SmartCue, I had grown tired of waiting on outsourced developers to make changes to a product I owned. AI gave me a way to do the work myself. I've written about what happened next: getting access, discovering problems, fixing things that should already have worked. Paying an external team hadn't relieved me of responsibility for the product my customers were paying for.

At OneDigital, we tried building the platform underneath our AI coworker program. We had engineers. We could build software. What we didn't have was a compelling reason to make maintaining an AI platform one of their continuing priorities.

We chose Cassidy. Usage increased. New capabilities arrived frequently, sometimes weekly. The program began getting traction. We still had plenty of work to do: choosing useful workflows, getting people to use them, teaching the coworkers, supervising the results. That was where our knowledge of the business mattered.

Maintaining our own platform kept competing with that work.

The tempting comparison was our development cost versus their subscription. The consequential comparison was what our people would spend their time doing after either decision.

AI makes the first comparison look increasingly attractive. It can make the second remarkably easy to skip.

I saw that happen recently in a conversation with a financial-services business. They had used Claude to put together a prototype for an internal system. The ambition was understandable: bring scattered processes into one place, make approvals easier, give employees something that fit how the company worked.

But the conversation kept returning to how straightforward it would be to build. Familiar workflows. Internal users. Requirements that weren't expected to change much. They had technical people already.

This was a publicly listed business discussing a system that could become its source of record for hundreds of employees.

“Internal” was doing an extraordinary amount of work in the argument.

A system doesn't become less consequential because customers can't log into it. Employees use its records to approve payments, resolve discrepancies, decide what has happened and what needs to happen next. When the records disagree, somebody has to establish which version the business can trust.

That responsibility survives every improvement in how quickly the screens can be built.

The October 21 critical PHP security release makes the point particularly well. Your requirements can remain completely unchanged while something underneath your application urgently needs fixing. That obligation exists whether AI wrote the application or a team of experienced developers did.

We ended up discussing estimates and comparing options. But the confidence had arrived well ahead of the answers that would justify it.

What bothered me was the assumption underneath that confidence: when the software needed attention, the technical team would somehow have time.

This is how a cheap project acquires an expensive claim on a business.

Before launch, the work is discretionary. Someone can fit it around other priorities. After enough employees depend on it, that arrangement changes. A broken approval flow doesn't wait patiently behind the engineering roadmap. An unreliable record cannot be left until the developer has a quieter week.

The business has created a permanent obligation without necessarily deciding what it will stop doing to fulfil it.

You don't need a full-time engineer for every internal tool. You do need an honest answer about whose existing work loses when the tool needs them. “Our developers will handle it” conceals that choice.

And a successful tool can make the choice harder. People adopt it. Other processes connect to it. Exceptions accumulate. What started as a useful shortcut becomes something you have to consult before changing anything else.

You can arrive at a critical system one sensible little addition at a time, without ever making a deliberate decision to operate one.

That's why I don't find “we can build it” particularly useful as a business case anymore. Increasingly, of course you can. The demonstration that used to establish technical feasibility now risks ending a discussion it should barely have started.

Before approving the build, I'd want three things made explicit.

What advantage are we getting in return for taking this on? There should be a specific answer: serving customers in a way existing products cannot, improving an important workflow, retaining control over something that determines the business's performance. At SmartCue, the software is the product my customers pay for. Giving it my attention is part of running the business. An internal platform needs its own justification. The fact that we already employ developers doesn't supply one.

Whose work gets pushed back when this needs attention? Name the person, the time available and the priority they are allowed to displace. Include the expertise needed to recognise a serious problem. If the plan depends on someone finding time between their actual responsibilities, the business hasn't really decided to support the software. It has decided to hope.

What happens when it gets something wrong? Can we spot the mistake, recover the records and keep working? Can we get our data out if we decide to replace it? A tool that produces a draft someone checks gives you room to experiment. A system whose records other people act on needs a much stronger answer before it becomes part of daily operations.

Those questions also help decide how much to build. A useful custom tool doesn't have to become an entire custom platform.

At Mark IT, our family's business, AI now does work we previously paid an agency to do across our website, content and search presence. We've also changed how we handle outreach. Taking that work in-house makes sense because we know the customers, the services and the message. We can inspect the output and make it better.

But our years of customer and service history remain in Zoho.

We can change how we reach customers without taking responsibility for rebuilding the system that holds those records. That boundary lets us put more effort into work where our knowledge matters.

A small business can make that distinction. So can a publicly listed company with an engineering team. Having more people doesn't settle which responsibilities are worth giving them.

I know how satisfying it is to see an idea working on a screen, and how quickly that satisfaction can start supplying its own justification. I've felt it myself. The ability to build something can feel like permission to make it everyone else's responsibility.

Before approving the next internal build, imagine a vendor making the same pitch. The demo works. Maintenance will happen when someone has time. Support will compete with other projects. The long-term cost hasn't been worked out.

Would you trust that vendor with the company's source of record?

Your own team deserves a fair hearing. It shouldn't get a lower bar.