A finance manager spent a weekend building a cash flow dashboard with an AI coding tool. It worked well. Six months later it stopped pulling data overnight and nobody in the business knew why.

This is happening across Australian businesses right now. Staff are using tools like GitHub Copilot, Cursor, Claude and ChatGPT to build genuinely useful internal applications: spreadsheets that became apps, forms that became workflows, scripts that became scheduled jobs. Nobody approved a project. Nobody owns the result. When it breaks, there is no support contract to call.

Why This Keeps Happening

AI coding tools removed the biggest barrier to building software: you used to need a developer. Now a reasonably tech-comfortable staff member can describe what they want in plain English and get working code back. For simple internal tools, this is genuinely valuable. It solves real problems faster than waiting months for an IT project to get prioritised.

The problem is not that the app got built. The problem is that nobody planned for what happens after that.

What Happens When It Breaks

Three things usually go wrong, and they tend to compound each other over time.

The builder moves on. Staff change roles, go on leave, or leave the business entirely. The person who understands how the tool works is often the only person who does. When they are no longer available, that knowledge leaves with them.

Nobody documented the dependencies. AI-built apps frequently connect to other systems: an API, a spreadsheet, a cloud folder, an email inbox. When one of those changes, such as a password reset, the app can fail silently. Nobody monitors it because it was never registered as a system needing monitoring.

IT does not know it exists. A tool built outside any formal process rarely makes it onto an asset register. When a staff member raises a ticket saying the app is broken, the service desk is troubleshooting something they have never seen before, with no documentation and no original author to call.

The Real Cost

None of this is hypothetical. We see it in client environments: a self-built rostering tool that silently stopped syncing with payroll, a custom invoice tracker that quietly lost months of records after a spreadsheet structure changed. The fix is rarely difficult once someone understands the tool. Getting to that understanding, with no documentation and an absent builder, is where the real cost sits.

What to Do Instead

The answer is not to ban staff from building things. Useful tools built quickly are a genuine productivity win, and blocking that entirely just pushes the behaviour further underground. The better answer is bringing these tools into a lightweight governance process before they become critical to daily operations.

• Keep a simple register of any internally built tool, who built it, and what it connects to
• Require a short handover note before the builder changes roles or leaves the business
• Have your IT provider review any tool that touches client data or financial records
• Decide in advance who owns the tool if the original builder becomes unavailable

This takes an hour per tool, not a project plan. It is the difference between a staff-built app being an asset and being a liability waiting to surface at the worst possible time.

Where Otto IT Fits In

Our managed IT support team can bring existing AI-built tools under proper support, and our automation and AI consulting practice can help you decide which ones are worth formalising versus rebuilding properly. If your business has grown a small collection of staff-built apps over the past year, talk to us about getting them supported before one fails at the wrong moment.

Frequently Asked Questions

Should we just stop staff from building their own tools?

Not necessarily. Many of these tools solve real problems faster than a formal IT project would. A lightweight review process works better than an outright ban, so the business keeps the benefit without the hidden risk.

How do we find out how many AI-built tools already exist in our business?

A short internal audit, usually a handful of targeted conversations with team leads, is the fastest way to surface what already exists. Most businesses are surprised by how many informal tools are already in daily use.

Can our existing IT provider support a tool they did not build?

In most cases yes, provided there is enough information about what the tool does and what it connects to. The earlier this review happens, the easier it is to document and support properly.