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.

Rebuilding capabilities a vendor was already working on kept competing with it.

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.

This week's 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.

I would make the decision under a deliberately generous assumption: suppose the first version costs nothing to build. Would we still want to own this software?

Then I'd ask three questions.

What can we do materially better by owning it? There should be a specific answer: serve customers in a way existing products cannot, improve an important workflow, retain control over something that determines the business's performance. Having slightly nicer screens is a different proposition from owning the system that keeps the company's records. Price the smallest useful piece of custom software before volunteering for the whole platform.

Who is responsible when keeping it useful competes with their other work? Name the person, the time available and the priority they are allowed to displace. Include the expertise needed to recognise a serious problem. Access to an AI coding tool doesn't answer any of those questions.

What would make us stop? Decide how you'll judge the result, how you'll recover from mistakes and how you'll get the data out. The more of the business depends on the system, the more convincing those answers need to be. “We'll fix it as we go” is easier to accept when a mistake is visible and reversible than when it quietly corrupts the record everyone else relies on.

Those questions should make some projects easier to approve. They should kill others.

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 haven't needed to rebuild the system of record to change what we can do with it. That's a much more useful ambition for many businesses: own the part where your knowledge makes a difference, and make the infrastructure earn its place through how well it supports you.

A small business can do this. So can a large one. Headcount isn't a substitute for making the distinction.

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.