Council Post: How To Govern Citizen Development Without Killing The Momentum
Joe Zein is the co-founder at Soal Labs, where he oversees engineering. Soal Labs is a data and AI consultancy for Private Capital GPs.
getty
In the age of AI, the same scenes are playing out inside companies everywhere.
Someone in sales built a lead scorer application over the weekend. An operations analyst spun up an HTML dashboard that finally shows the numbers the way the team actually thinks about them. A finance associate prototyped a reconciliation tool. An intern three weeks into the job shipped a data cleanup script that works better than the process it replaced.
These are citizen developers. Because these people are not engineers, none of them went through any kind of planning process. None of them gave a thought to authentication, permissions, security or how the thing would hold up once other people came to rely on it.
The tools that make this possible are already on your team's laptops, so citizen development is happening at your company. The only question is whether you build the guardrails before the second-order problems arrive, or after.
My strong view, after watching this unfold across several firms, is that shutting it down is a mistake. For years, teams sat through requirements sessions, nodded along, then ignored the delivered product because it never matched the workflow in their head.
When someone builds their own tool, they have handed you an exact spec for what they actually need. The speed is real and the engagement is real. As I put it to one leader recently, your people have been handed bazookas where the power is real, but the aim needs work.
How Citizen Development Breaks Down
In my experience, the trouble shows up around the tenth prototype, and it tends to creep in quietly.
First, the data splinters. Every tool carries its own list of customers or accounts and its own version of the truth, none of which connect to the systems of record, because real integration takes engineering judgment that a weekend build skips. So you end up with "Acme Corp" in one tool, "ACME Corporation" in another and "Acme" in a third. You have more silos than you started with, except now they feel like finished products to the people who made them.
Then comes redundancy. Two people on different teams build trackers that solve almost the same problem in incompatible ways. I have watched leaders triage this personally, every day, pulling someone aside to say that nearly every team could use what they built, so let us make it more generic than you first imagined.
The one that should worry you most is security. Almost every quick-built internal tool I have looked at has carried at least one problem the person who made it never noticed: a secret key left in the code, an open database or a set of default credentials nobody changed. The tool works, so everyone assumes it is safe. In practice, that means a weekend project might be sitting on sensitive customer or financial data with the front door effectively unlocked, and no one would find out until it was too late to be quiet about it.
Last come the orphans. The person who built the tool in February gets pulled onto something else in March. When it breaks in April, you now own a production system you never built and cannot easily retire. Eventually someone asks how a number reached an executive report, and "someone built an app that reads a spreadsheet" is not an answer anyone wants to give.
Building The Governance Framework
The fix is not a ban. Instead, companies should build a shared infrastructure plus a light layer of governance.
A shared data layer is the prerequisite. If every tool queries the same canonical tables through the same endpoints, fragmentation mostly disappears, because the data model gets defined once by people who understand the domain.
Managed infrastructure, deployed centrally, can enforce what individuals cannot override: which tools and data sources are allowed, security guardrails and consistency. Shared templates and starter files similarly give builders a running start instead of a blank page.
And you need a clear path for how a weekend prototype gets reviewed, promoted to production or retired gracefully with its requirements captured.
All of this needs a small team that owns the platform, sets the rules, reviews prototypes and sits with people to show them a better way to do what they were already trying to do.
Plenty of companies outside of tech run lean technology functions focused on IT operations, which is a different discipline from product engineering. Whether you build that capability or borrow it, the principle holds. Let AI handle volume and speed. Let your process and your people handle quality and judgment.
The citizen developers are not going away, and the tools will only get better. The only question worth asking is whether your harness is ready before the tenth prototype, not after.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?