Who maintains the AI tool your team just built?

Something changed in the last eighteen months. A capable person inside a business — often not a developer — can now describe what they want to a coding tool and get working software back. Not a mockup. Something that runs.

I've watched businesses build genuinely useful internal tools this way. A quoting calculator. A rota system. A dashboard that finally pulls two systems together. Built in days, for the price of a subscription.

Then, three months later, I get the call.

What actually goes wrong

It's almost never that the tool doesn't work. It worked fine on day one. It's one of these:

The person who built it moved on. They changed roles, left, or simply got busy. Nobody else can read the code, and the AI that wrote it has no memory of why any decision was made.

Something upstream changed. An API version was deprecated. A supplier changed their export format. The tool breaks, and the error message means nothing to anyone in the building.

It worked until it had real data in it. Fine with fifty rows, unusable at fifty thousand. Nobody tested that, because on day one there were fifty rows.

It quietly did something wrong. This is the expensive one. The tool ran, produced numbers, and everyone trusted them. The mistake surfaced in an invoice, a stock count, or a client report — months of it.

None of these are AI problems. They're the ordinary problems of owning software, arriving at businesses that have never owned software before.

The thing nobody budgeted for

Building software has always been the cheap part. Maintenance is where the money goes — the industry rule of thumb is 15–25% of the original build cost, every year, indefinitely.

AI collapsed the build cost. It did not touch the maintenance cost.

So the ratio has quietly inverted. A tool that would have cost £30,000 to build and £6,000 a year to maintain might now cost £2,000 to build — and still cost something meaningful every year to keep alive. The maintenance is no longer a fraction of the build. It's the whole cost.

That's not an argument against building. It's an argument for knowing what you're signing up to.

Three questions to answer before you build

Not after. Before.

1. Who is the second person?

If the person who built it is unavailable for a month, who keeps it running? If the honest answer is "nobody", you haven't built a tool. You've built a dependency on one person's availability.

2. How would you know if it broke quietly?

Loud failures are easy — someone shouts. Quiet ones are what hurt. What would tell you the numbers went wrong three weeks ago? If nothing would, add something that does before you rely on the output.

3. What happens when it becomes important?

Internal tools have a habit of getting load-bearing. The spreadsheet that ran a department for nine years started as somebody's weekend project. Decide now what the threshold is at which this needs to be built properly — and what "properly" means.

What good looks like

When I hand over a system, it comes with a handover pack, and I think this is a reasonable bar for anything you build internally too:

• A written explanation of why, not just what. Future-you needs the reasoning, not a description of the code you can already read.
• Tests on the parts that matter. Not everything. The bits where a silent error costs money.
• A runbook. What breaks, how you'd know, what to do about it. In plain English.
• Somewhere for it to live that isn't one person's laptop or personal account.
• A named owner inside the business, with the time to be that owner.

If a supplier hands you working software with none of that, you haven't bought a system. You've bought a countdown.

The honest version

I make my living building this kind of software, so read the following knowing that.

Sometimes you should not build it. If an off-the-shelf product does 80% of the job for a subscription you can afford, buy the product. The subscription you resent is almost always cheaper than the maintenance you can't escape. I say this to people who arrive wanting to build, and it costs me work.

Build when the thing you need genuinely doesn't exist, when the product you'd buy would cost more over three years than owning it outright, or when the process is your actual competitive advantage and bending it to fit someone else's software is the real cost.

And when you do build — build it so it survives you. That's the whole job.

---

If your team has built something with AI and you're not sure who's holding it up, that's a conversation worth having before it breaks rather than after.