AI lets employees build internal tools fast, but nobody plans who maintains them. The questions to ask before an employee builds, alone, a tool the business comes to depend on.
The fastest internal tool you'll ever get is the one an employee builds on a Friday afternoon. A few prompts, a spreadsheet export, an API key, and by Monday a colleague is using it to reconcile invoices or triage support tickets. It works. It saves hours. And in most companies, nobody asks the question that decides whether it was a good idea: who maintains this when its author changes team, gets promoted, or leaves?
This is the quiet failure mode of AI-assisted development. The tools arrive faster than the ownership around them. Below is a practical way to think about it before the tool becomes something the business can't switch off.
The maintenance gap nobody plans for
A tool built by one person usually carries invisible dependencies: their personal account on a model provider, a script on their laptop, a cron job they remember to restart, undocumented assumptions about a database schema, and knowledge that lives only in their head. None of this shows up in a budget line, so none of it gets managed.
The risk isn't that the tool is badly written. It may be perfectly fine. The risk is that the cost of maintaining it was never counted, and the person who would have paid it is gone. When that happens, you face a choice between a rewrite, an emergency contractor, or quietly abandoning a process people now depend on. That last option is often the most expensive, because the work silently flows back to manual effort.
Questions to ask before the build starts
You don't need a heavy approval process. You need five honest answers, written down, before anyone builds a tool others will rely on.
- Who owns it after launch? A named person and a named backup, not "the team." Ownership means someone is accountable for it breaking.
- What happens if the builder leaves? If the answer is "we'd have to ask them," the tool isn't ready to be depended on.
- Where does it run? On a laptop, a shared server, or a managed platform? Tools that only run on one machine are prototypes, not systems.
- What does it touch? Which data, which systems, which credentials. This determines the blast radius when something goes wrong.
- How would someone else change it? If nobody else can read or safely modify it, it's a single point of failure.
If these questions feel bureaucratic for a small script, that's a signal the tool is still a prototype. Prototypes are fine. The mistake is letting a prototype quietly become infrastructure without anyone deciding that it should.
Shadow IT with AI is different
Employees have always built spreadsheets that became business-critical. AI changes the scale and the surface area. A modern AI-assisted tool can call paid APIs, process customer data, and make decisions that look authoritative. That raises three concerns that spreadsheets rarely did:
- Cost. Model calls cost money per use. Without visibility, a helpful tool can generate a bill nobody forecast.
- Data. Sending customer records or internal documents to an external API is a data-handling decision, not an implementation detail. It needs to be a conscious one.
- Trust. AI outputs can be wrong in ways that are hard to spot. A tool that quietly produces plausible-but-incorrect results is worse than no tool.
None of this argues against employees building things. It argues for lightweight guardrails: a short checklist, a register of tools in use, and a clear line between "personal productivity script" and "tool the team depends on."
Low-code versus custom code: a maintenance question
The low-code versus custom debate is usually framed around speed. For internal tools, frame it around maintenance instead. Ask who will fix it in two years.
Low-code and no-code platforms lower the barrier to building, which is exactly why they produce so many ownerless tools. They also concentrate risk in the vendor: pricing changes, feature removals, export limits. Custom code gives you control and portability, but only if it's written to be maintained by someone other than its author, with documentation, tests where they matter, and standard deployment.
The honest rule: the more people depend on a tool, the more its maintenance should look deliberate. A throwaway script can be scrappy. A system three teams rely on cannot.
Making handover normal
The most reliable fix is cultural. Treat handover as part of building, not an afterthought.
- Require a short README for any shared tool: what it does, how to run it, where credentials live, who to contact.
- Keep credentials in a shared, access-controlled store, never in personal accounts.
- Put shared tools in a repository or workspace the team controls, not a personal drive.
- Schedule a periodic review of internal tools: still used, still owned, still safe.
- When someone leaves, include their tools in the offboarding checklist alongside their accounts.
None of this is glamorous. All of it is cheaper than an emergency reprise of a tool the business suddenly can't run without.
The point isn't to slow people down
Employees building their own tools with AI is a genuine advantage, and clamping down on it wastes that. The goal is to make the difference between a prototype and a system explicit, so the business knows what it's depending on and who's responsible when it needs care. Innovation that serves people includes the people who inherit the work.
If you're seeing internal tools multiply faster than you can track them, or you've inherited one and aren't sure how maintainable it is, that's a good conversation to have early. Get in touch and we can look at what you have and what it would take to keep it running.