Insights
People who have never written code are now building working tools for their own teams. Picture a finance analyst who automates the monthly report, an operations lead who builds an intake form that routes requests to the right person, or a sales coordinator who sets up a check for missing fields in contracts. Most of this happens without IT being asked, and often without IT knowing.
That is not a problem in itself. The question is who is responsible for these tools once they exist.
The gap between “I have a problem” and “I have a working tool” used to be measured in months. It now takes days, sometimes an afternoon. That shift matters less for the speed than for who does the building.
The person closest to the problem now builds the solution. Nothing gets lost between the team that needs the tool and the team that writes the specification. The result is often better fitted to the real work than anything a central team could have built from a brief.
Data nobody mapped. A tool built in an afternoon may handle customer or employee data without anyone checking what the GDPR requires. The builder is rarely careless. They simply were not asked to think about it.
Tools with one owner. When the person who built it changes role or leaves, the tool keeps running and nobody knows how it works. It tends to break at the worst moment, such as month-end.
Quiet duplication. Three teams build three slightly different versions of the same report, and the numbers stop matching. Nobody did anything wrong, yet the organisation now has three answers to one question.
Access creep. Quick tools are often connected to other systems with broader permissions than they need, because that was the fastest way to get them working.
A tool built by a non-engineer is rarely built for scale, security review or long-term upkeep. It solves one person’s problem well and may not survive a second user, a second dataset or a change in the system it depends on.
Some work should still go to engineers. As a rule of thumb, anything that touches customer data, financial reporting or a system of record needs proper review before people rely on it. The aim is to keep the speed of the first group of tools without letting them quietly become critical infrastructure.
The answer is not to ban these tools. People will build them anyway, and a ban only moves the activity out of sight. Three light mechanisms are enough.
A simple register. Every tool has a name, an owner and a note of what data it touches. A shared spreadsheet is enough. What matters is that it exists and people actually use it.
A short path to review. A builder should be able to get an engineer to look at their tool within days. If review takes weeks, people will skip it and keep the tool quiet.
A clear promotion rule. Decide in advance when a tool has become important enough to be handed to engineers and rebuilt properly. Usage by more than one team, or any link to customer or financial data, are sensible triggers.
You can start improving your setup now without new tooling or budget.
If the person who built your most-used internal tool left tomorrow, who would know it exists?
Choose a preferred time slot and tell us what you would like to explore. We will confirm the meeting and send you the invite.