The new shadow IT — when everyone can build a module

The change-request queue was hated for good reason. You wanted a field; you got a quote and a four-month wait. Everyone has a story.

But the queue was doing three jobs nobody credited it for:

1. It forced a moment of thought. Anything worth four months of waiting got considered properly. Most bad ideas died in the queue, which is the cheapest place for a bad idea to die.
2. It gave one person a view of the whole. Someone saw every request and noticed when two departments asked for the same thing.
3. It created a record. There was a list of what existed and why.

Remove the queue — which is exactly what AI-native tooling does — and those three jobs do not disappear. They become nobody's, silently. This is our own failure mode and it is worth being precise about, because it is the most likely way an AI-native rollout goes wrong.

What it looks like when it goes wrong

Not dramatic. That is the problem — nothing breaks, it just degrades.

Month one: three managers build three genuinely useful things. Everyone is delighted. Someone says "why did we ever need IT?"

Month four: there are eleven modules. Two do nearly the same thing with different field names. One is abandoned but still emailing people every Monday and nobody knows how to stop it. The person who built the good one left.

Month nine: someone asks "how many open jobs do we have?" and gets three different answers from three systems, all of which are technically correct. Finance has stopped trusting the dashboards and rebuilt a spreadsheet. You are back where you started, except the mess is now in software and harder to see.

None of that required anyone to do anything wrong. Every individual decision was reasonable. That is what makes it likely — it is the default outcome of removing friction without replacing what the friction provided.

Why this is not the same as spreadsheet chaos

Two differences, one better and one worse.

Better: it is at least visible and auditable. Spreadsheet chaos lives on eleven laptops. Module sprawl lives in one system, with logs. You can see it, list it, and clean it up. That is a real improvement.

Worse: it is faster and it looks official. A spreadsheet announces what it is — everyone knows it is Ah Ling's file and treat it accordingly. A module with a proper form and a dashboard looks like a system. People trust it more than it has earned, and act on numbers nobody validated. The presentation outruns the governance.

That second point is the real risk. The output of a half-thought-through module looks exactly as authoritative as the output of a good one.

The governance you actually need

Not a committee. Four things, and they are boring on purpose.

1. Someone owns each thing

Every module has a named owner. Not a builder — an owner, who is accountable for whether it still makes sense. If the answer to "who owns this?" is a shrug, the module should be archived. That single rule kills most sprawl before it compounds.

When people leave, ownership transfers explicitly. The most common failure we see is an orphaned module that everyone depends on and no one understands.

2. Two tiers, not one gate

Do not put a queue back — that discards the benefit. Split by consequence:

• Personal and team-level things: build freely. A tracker for your own team, a form for one process. Low blast radius, high value, no permission needed. This is most of it.
• Things that touch money, customers or the shared record: these need review. Not a four-month queue — a conversation with someone who has the whole picture.

The failure is treating both tiers the same. Gate everything and you have rebuilt the old world at a higher price. Gate nothing and you get month nine.

3. A visible register

A list of what exists, who owns it, what it is for. Sounds bureaucratic; takes an hour a month.

It is how you catch the two-modules-doing-the-same-thing problem before it becomes three answers to one question. The old change-request log did this by accident. Now it has to be deliberate.

4. Periodic archiving

Most modules have a natural life. A project ends; its tracker does not. Once a quarter, go through the register and archive what nobody uses. Archive, not delete — the point is reducing what looks live.

An abandoned module that still sends emails is worse than no module, because it produces output people half-trust.

The trap: over-correcting

Having read the above, the instinct of anyone who has run a proper IT function is to install a change board.

Do not. You will have spent money on tooling that removes the translation layer, then reinstated the queue that the translation layer's cost created in the first place. You get the licence fee and none of the benefit, and your users will route around you — back to spreadsheets, where at least nobody asks permission.

The friction was never the goal. The goal was thought, oversight and a record. Friction was just the cheapest way to get them when change was expensive. Now that change is cheap, buy those three things directly — ownership, tiered review, a register — and leave the friction out.

This is the same reasoning as agentic ERP: when you remove a human step, you must ask what that step was providing and replace it deliberately, rather than assuming it was pure overhead. Sometimes it was pure overhead. Usually it was doing something quietly.

Who should own this

Somebody, specifically, and preferably not IT.

The natural owner is whoever understands the business end-to-end — often a COO, a finance manager, sometimes the founder. It needs to be someone who can say "you two are building the same thing" and be listened to.

It is not a big job. An hour a month, once the register exists. It is just nobody's job by default, and that is precisely how you get to month nine.

Ownership, two tiers, a register, quarterly archiving

The change-request queue was a bad solution to a real problem. Deleting it without replacing what it did is not liberation — it is deferral, and the bill arrives around month nine.

Ownership, two tiers, a register, quarterly archiving. That is the whole thing. It is unglamorous, it takes an hour a month, and it is the difference between an AI-native rollout that compounds and one that quietly becomes the mess you were escaping.

Common questions

What goes wrong when everyone in the business can build a module?

Nothing breaks. It degrades, which is worse. Month one, three managers build three genuinely useful things and everyone is delighted. Month four there are eleven modules, two doing nearly the same thing with different field names, one abandoned but still emailing people every Monday. Month nine, "how many open jobs do we have?" gets three different answers that are all technically correct, and finance has quietly rebuilt a spreadsheet.

Should I put an approval queue back to keep control?

Do not — that discards the benefit you paid for and your users will route around you, back to spreadsheets where nobody asks permission. Split by consequence instead. Personal and team-level things, a tracker for one team or a form for one process, get built freely with no permission needed; that is most of it. Things touching money, customers or the shared record get reviewed, meaning a conversation with someone who has the whole picture.

Is module sprawl just spreadsheet chaos again?

It differs in two ways, one better and one worse. Better: it is visible and auditable, living in one system with logs rather than on eleven laptops, so you can see it, list it and clean it up. Worse: a module with a proper form and a dashboard looks like a system, so people trust it more than it has earned and act on numbers nobody validated. The presentation outruns the governance.

Who should own governance of what gets built?

Somebody specific, and preferably not IT. The natural owner is whoever understands the business end to end — often a COO, a finance manager, sometimes the founder — someone who can say "you two are building the same thing" and be listened to. Once a register of what exists is in place, it is about an hour a month. It is simply nobody's job by default, which is exactly how you get to month nine.

If you want to work out what this would look like in your business, talk to us — including if the honest answer is that you are not ready yet.

Related: what AI still cannot do in ERP, where this is one of seven, and Vibe ERP explained for the method that makes it necessary.

Also worth reading: moving approvals off WhatsApp.