Dark IT: Paving the Desire Path

Citizen Developers, Dark IT and the Queue at the Gate

Walk across any university campus or business park and you'll see them: thin brown tracks worn through the grass, cutting the corner the architect drew. Planners call them desire paths. They are the routes people actually take when the official one is longer than it needs to be, and they carry a useful lesson. You can put up a fence and a sign. Or you can notice where everyone is walking and pave it.

I should declare an interest, because I've worn a few of those paths myself. I started building tools in Excel, the way a lot of people do: a formula to save repeating the same sum, then a lookup, then a workbook other people started asking for. Then macros, then VBA, then Power Automate and Power Apps. Each step came from the same place. There was a problem in front of me, a tool I already had access to, and no realistic prospect of it being solved any other way.

That is how citizen development has always worked, long before anyone gave it a name. What has changed is the speed.

I've written before that a working demo beats a requirements document for winning buy-in, and that AI has made demos cheap enough for almost anyone to build. That is the good news. This is the other side of it. When anyone can produce a convincing, working tool in an afternoon, the organisation doesn't just get more good ideas. It gets more software. Lots of it, built by people who are not developers, running in places nobody in IT is looking.

When I was learning an new tool, the effort of building was its own filter. If an idea wasn't worth the hours it took to get the code working, it didn't get built. Across a whole organisation, that cost did a quiet governance job nobody noticed. Most bad ideas never made it far enough to need approval, so IT's gate only ever had to handle a trickle.

That filter has gone. The gate hasn't changed, but the trickle has become a flood: AI-built demos, automations and small apps, each one somebody's sensible fix for a real problem, all queuing for the same handful of people. A review process built to clear a few requests a month cannot absorb that volume, and when a queue can't be cleared, people stop joining it. Not out of recklessness, but because the tool works, the problem is real and the official route is six weeks long.

The result is dark IT: working software the organisation depends on but cannot see. It is the application equivalent of dark data, with a twist that catches people out. Much of it isn't running on unsanctioned tools at all. The Cloud Security Alliance has pointed out that vibe-coded shadow applications are frequently built on approved enterprise platforms. A small app in the company's standard environment, wired to a shared list, passes every "approved software" check while having no owner, no review and no plan for what happens when its builder moves on. An approved platform is not the same thing as a governed one. Looking back honestly, some of what I've built over the years would fit that description.

The two constraints I've run into most often as a builder aren't technical. The first is budget. A citizen developer builds with what they're already licensed for, not with what would be right for the job. I've built things with a spreadsheet and a standard connector that arguably belonged on something more robust, because the more robust option had a price attached and the workaround didn't. That is a desire path too: the route people take when the paved one has a toll on it.

The second is knowledge. Not of the tool, which can be learned, but of the organisation and its processes: which other system already holds this data, who else depends on this step, which rules exist that nobody ever wrote down. It's entirely possible to build something that works perfectly for one corner of the business and still duplicate a record held elsewhere, or break an assumption another team relies on. That knowledge sits with IT and with the wider organisation, and it's exactly what a citizen developer working alone tends to lack. It has changed how I think about the gate. The most valuable thing IT can offer a builder isn't permission. It's the context the builder doesn't have.

None of this is a discipline problem, and tightening the gate won't fix it. The citizen developer gets the benefit of speed straight away. IT inherits everything that follows: the support call, the security review, the data protection question, and the maintenance once the builder changes roles and the app becomes somebody's unacknowledged second job. While the benefit and the cost land on different people, no amount of policy will make the queue attractive. Sometimes the official route is longer for reasons nobody chose. A Mac user in a Microsoft shop may need a virtual machine to run the sanctioned tools, while an AI coding assistant runs happily on their laptop. Nobody set out to build shadow IT. The paved road was simply further away.

So when should a citizen developer engage IT? Not at the idea stage, which would only recreate the queue, and not after launch, when it's too late to matter. The test I'd offer, and the one I try to hold my own work to, is the moment the demo gets users: when someone else relies on it, when it writes to a system of record rather than just reading from one, or when it touches personal or sensitive data. Before that point it's an experiment. After it, it's production, whether or not anyone has called it that.

How you engage matters as much as when, and this is where the humble requirements document makes its comeback. The demo's job was to win the room. The memo's job is the handover: what the thing does, what data it touches, who owns it and what happens when it fails. Demo to win support, memo to hand over. A builder who arrives with both is asking IT for a review. One who arrives with only a demo is asking IT to adopt a stranger.

On the other side, IT's role has to shift from guarding the gate to paving the road. Speaking as a builder, what I want isn't fewer rules. It's a route where the rules come built in, so doing the right thing doesn't cost months. In practice that means a sanctioned platform where security, access control and audit trails are inherited by every app rather than reviewed one at a time; tiers that separate a personal tool from a team tool from something the business runs on; and review effort spent on the promotion to production rather than on every experiment. You stop inspecting each footstep and start maintaining the path.

The vendors have noticed. Microsoft and ServiceNow, the two platforms I spend most of my time in, have both put AI app generation inside their governed environments, so that whatever gets built inherits the controls by default. A newer group of tools goes further and concedes the point entirely: build wherever you like, but ship through one governed runtime. That is a telling admission. The market has accepted that you can't control where people build, only where their work lands.

The honest caveat is that a safe platform makes governance possible, not automatic. The organisations doing this well at scale still fund a central team to maintain the rules, pay for the licensing that enables them and give someone the job of owning the whole thing. The platform doesn't remove the second job. It gives it a name, a budget and an owner, which is more than it ever had before.

Citizen development isn't the problem. It's the most direct evidence an organisation will ever get of where its official routes are failing the people who use them. Every tool I've built started as a desire path: a record of where I needed to go, and how far the paved route was from getting me there. Fence those paths off and people will simply wear new ones. Treat them as the most honest survey of demand your IT function will ever receive, and you get to pave the ones worth keeping.