Nobody sets out to build this arrangement. It arrives on its own, and it always arrives the same way.
A sales team builds a customer follow-up tool. It works. It uses an export of the customer list, because that was the only way to get the data. Over nine months it becomes how follow-ups happen. Then somebody asks a question — during a security review, or a POPIA assessment, or after an incident — and engineering is handed the thing and asked to make it production ready.
At which point the conversation goes badly, for reasons that are entirely predictable and have very little to do with anyone's competence.
Why it goes badly
The request "make this production ready" sounds reasonable and is close to meaningless. What it actually asks for, in the case above, is: reverse the data architecture, because the customer export should never have existed. Add an identity model, because there isn't one. Establish a retention rule for conversation history that has been accumulating for nine months. Work out whether the prompts sent to a third-party provider contained personal information, and if so, notify accordingly. Then find someone willing to own it.
That is not remediation. It is a rebuild with a hostage — because the business cannot stop using the tool while you rebuild it, and every decision is now constrained by choices made by someone who had no reason to know they were making architectural decisions.
The engineering team's frustration is legitimate. So is the business team's. They solved a real problem with the tools they had, delivered value for the better part of a year, and are now being treated as though they did something wrong. Both reactions are reasonable and the combination is corrosive, which is what makes this an organisational failure rather than a people failure.
What was actually true all along
The most useful thing about this anti-pattern is that the discoveries are so consistent. It is almost always the same five.
Read the left column carefully: nobody lied. Every statement was accurate on the day it was made. The tool genuinely did only read a CSV. Three people genuinely were the only users. The person who built it genuinely was supporting it.
What is missing is not honesty. It is any mechanism by which those statements get revisited when they stop being true. The tool crossed from "personal productivity" to "business critical" without a moment at which anyone noticed, because there was no checkpoint to notice at. That is the entire defect, and it is a process defect, not a behaviour one.
The costs that are easy to miss
The obvious risks — data exposure, no audit trail, no owner — get discussed. Three quieter costs do more damage over time.
Duplication. Four teams independently build four versions of roughly the same thing, none of which know about each other. Later, someone tries to consolidate, and discovers that each version encodes slightly different business rules, all of which somebody depends on.
Poisoned goodwill. After one of these episodes, the business team learns that showing engineering what they built produces a lecture and a project. So the next tool is not mentioned. Every organisation with a genuine shadow IT problem built it themselves, one discouraging conversation at a time — and AI has simply increased the rate at which unmentioned tools appear.
Ownership fiction. The tool ends up formally owned by a team that did not build it, does not understand the business rules inside it, and cannot change it safely. It then survives for years in a state where everyone is afraid of it. This is a remarkably common terminal state.
The route that replaces the wall
The fix is not more control. It is an earlier, cheaper checkpoint — and the design constraint that matters is that it must cost the builder almost nothing, or it will be skipped.
Registration, taking about thirty seconds. What is it, what data does it touch, who uses it, who built it. Not an approval request. A note. This single step converts shadow IT into an inventory, and an inventory is what makes everything else possible.
Classification by consequence. Who is harmed if this is wrong. Most things come back as "nobody much" and require nothing further, which is what makes the process survivable.
Approved starting points for the tiers that need them. If somebody is building something that will touch customer data, the useful intervention is a template that already handles identity and data location — offered before they start, not demanded after they finish. This is the paved road, and it is the reason platform engineering matters in this model.
Review proportional to the tier. Enterprise controls on a personal script teaches people to hide their work. Match the weight of the process to the size of the consequence.
A promotion checkpoint. The single most valuable trigger: when a tool crosses from "some people use it" to "a process depends on it", something happens. That is the moment the left-hand column above stops being true, and the only thing needed is for someone to notice.
The uncomfortable part
There is one honest caveat worth stating. A well-designed intake route does not eliminate this problem; it reduces it. Some tools will still slip through, because the person building them did not think of it as software — it was a spreadsheet, then a spreadsheet with a script, then a script with a model behind it, and at no point did it feel like a moment to register anything.
The response to that is not more enforcement. It is periodic discovery: occasionally going and looking, in a way that is explicitly framed as inventory rather than audit. The teams that do this find things, fix a couple of them, and — more importantly — demonstrate that finding things does not result in punishment. That demonstration is worth more than the policy.
How CloudNala can help
We are usually called in at the worst moment of this cycle: something has become load-bearing, somebody has noticed, and the organisation needs to know how bad it is. The first pass is triage and honesty — what is really running, what data is really moving, what would actually break. It generally turns out to be less catastrophic than feared and more widespread than expected. The second piece of work is the one that prevents the next round: a registration and classification route light enough that people actually use it, and approved starting points for the handful of categories that keep recurring.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Readiness Workshop or write to us at consult@cloudnala.co.za