# What is citizen development, and how does it avoid becoming shadow IT?

Letting the people with the problem build the solution works until nobody knows what exists. The governance that makes it sustainable, and the things it should not be used for.


Citizen development means people outside engineering building the applications and automations they need, using tools that do not require writing much code. The person with the problem builds the solution, which removes a queue and produces something that fits the actual requirement rather than a written description of it.

It works. What determines whether it is still working in three years is whether anybody knows what has been built — because the failure mode is not bad applications, it is an estate of useful applications that nobody has an inventory of.

## What we'll cover

- [What it is, and why it happens](#what-it-is-and-why-it-happens)
- [The shadow IT question](#the-shadow-it-question)
- [Classify by consequence](#classify-by-consequence)
- [What citizen developers should not build](#what-citizen-developers-should-not-build)
- [The inventory](#the-inventory)
- [Support that is not a gate](#support-that-is-not-a-gate)
- [When something outgrows the builder](#when-something-outgrows-the-builder)
- [Measuring whether the programme is working](#measuring-whether-the-programme-is-working)
- [Where CodeWords fits](#where-codewords-fits)
- [What to get right first](#what-to-get-right-first)
- [Frequently asked questions](#frequently-asked-questions)

## What it is, and why it happens

**People build their own tools** with low-code platforms, spreadsheets, automation builders, and whatever else is available.

**It happens because the queue is long.** A request that would take engineering two quarters takes the requester a week, and the requester has the deadline.

**It also happens because requirements are hard to transmit.** The person doing the work knows the exceptions; a written specification does not.

**It is not new.** Every spreadsheet with formulas is citizen development, and organisations have run on them for decades.

**What changed is the reach.** Modern tools connect to real systems and write to them, so the output is no longer confined to one person's file.

**Trying to stop it does not work.** The demand is real and the alternative is doing the work by hand, so prohibition produces concealment rather than compliance.

## The shadow IT question

The reasonable concern, stated precisely rather than as a reflex.

**The risk is not that people build things.** It is that nobody knows what exists, what it touches, and who is responsible.

**Data access is the sharpest version.** An application built by somebody with broad permissions can read and move more than its purpose requires.

**Business continuity is the slower version.** An application nobody knows about becomes load-bearing, and its builder leaves.

**Compliance is the third.** A process handling personal or regulated data, built outside any review, is a genuine exposure.

**None of these requires prohibition to address.** They require knowing what exists, which is a considerably easier thing to ask for than approval before building.

## Classify by consequence

The organising idea that makes governance proportionate.

**Personal tools** affect one person. A tidier inbox, a spreadsheet that organises somebody's own work. No oversight needed, and imposing any is how a programme gets a reputation.

**Team tools** affect a group and interrupt work when they break. An owner and an inventory entry.

**Business-critical tools** touch money, customers, regulated data, or a process the organisation depends on. A named owner, a review, and a plan for what happens if the builder leaves.

**Classify on what it touches, not on how it was built.** A complex personal tool needs less oversight than a simple one that writes to the billing system.

**Reclassify over time.** Tools graduate upwards quietly — the personal one that four people now rely on is the classic case — which is why the inventory needs revisiting rather than only populating.

## What citizen developers should not build

Not a matter of skill, but of consequence and of what these tools support.

**Anything holding regulated or sensitive personal data** without a review, because the obligations attach regardless of who built it.

**Anything customers interact with directly**, which carries brand and legal exposure most platforms are not set up for.

**Anything that must be auditable**, where a change history and a review trail are required and the platform provides neither.

**Anything writing to a system of record without validation**, since the downstream corrections cost more than the tool saved.

**Anything the organisation cannot afford to lose**, unless somebody has accepted that risk deliberately.

**Publish the list.** People generally respect a clear boundary and resent an unpredictable one, and the alternative to a published list is a case-by-case refusal that reads as obstruction.

## The inventory

The single highest-value practice, and it is a spreadsheet.

**What exists, who built it, who owns it now, what it connects to, and who uses it.** Five columns.

**Make registering easy** — a form, thirty seconds — because a registration process that takes an afternoon produces an inventory of the compliant minority.

**Give something in return.** Registered applications get support, a backup, or a route to being adopted properly. An inventory that only imposes obligations does not get filled in.

**Run a census periodically**, since voluntary registration is always incomplete. Ask each team what they use and check what the platforms themselves report.

**Reassign ownership when people leave**, as part of the leaving process, which is the moment the information is still available.

**The first census is always larger than expected**, and the applications nobody remembered are reliably the ones with no owner and the broadest access.

## Support that is not a gate

**Approval before building kills the benefit**, which was speed. A programme that reintroduces the queue has recreated the problem in a different department.

**Offer templates and patterns** for the common cases, so people start from something reasonable.

**Provide connections centrally**, so nobody is creating personal credentials with broad access to make their tool work — this is the single most effective technical control here.

**Be available to ask.** A named person or channel for questions catches most problems earlier than any review would.

**Review by consequence**, so the business-critical ones get attention and the personal ones do not.

**Say yes with conditions** rather than no, since the alternative to a supported tool is usually an unsupported one rather than no tool.

## When something outgrows the builder

**It will happen**, to a small proportion, and having a route matters.

**Recognise the signals**: several teams depend on it, it handles money or customers, it breaks in ways that interrupt others, or its builder has become an unwilling support function.

**Have a promotion path** — a known route to being rebuilt or adopted properly — rather than an argument each time.

**Do not punish success.** The person whose tool became critical did something useful, and treating the promotion as a confiscation discourages the next one.

**Keep them involved.** They know the requirements better than any specification will capture, and the rebuild without them usually loses the exceptions.

**Retire the original deliberately**, with a date, so both do not run in parallel indefinitely.

## Measuring whether the programme is working

Citizen development programmes get evaluated on the wrong numbers, which is why some good ones get shut down and some poor ones continue.

**Count applications in active use**, not applications built. An estate of three hundred where forty are used is a governance problem wearing a success metric.

**Count the requests that never reached engineering**, since that queue not forming is the actual benefit.

**Count applications that broke and who noticed**, which tells you whether ownership is real or nominal.

**Track how many were promoted** to being properly built, because that number is a sign of success rather than failure — it means the programme found things worth investing in.

**Ask the builders whether it saved them time**, since the answer is frequently more informative than any count and occasionally is no.

**Do not measure people on how many they build.** It produces applications nobody needed, and the estate becomes harder to govern in the name of a number.

## Where CodeWords fits

CodeWords is for the automation half: describe what should happen in plain language and it builds, connects, and deploys it across more than 3,000 integrations, with the connections made once and reused rather than each person creating their own.

1. Open [CodeWords](https://codewords.agemo.ai) and start a new automation.
2. Describe the outcome to Cody, the automation builder, including the exceptions.
3. Connect the systems involved once and reuse the connections.

The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the [pricing page](/pricing).

## What to get right first

The inventory, and making registration take thirty seconds. Every problem attributed to citizen development reduces to not knowing what exists, and every proposed solution that starts with approval reintroduces the queue that caused people to build their own tools in the first place.

Two habits make the difference. Give registered applications something — support, a backup, a connection they would otherwise have to create themselves — since an inventory that only imposes obligations stays empty. And reassign ownership as part of the leaving process, because that is the last moment anybody knows what the departing person built.

## Frequently asked questions

### Is citizen development the same as shadow IT?

No. Shadow IT is the state of nobody knowing what exists. Citizen development with an inventory and clear boundaries is a deliberate arrangement; without them it becomes shadow IT, which is a governance outcome rather than a property of the practice.

### Should there be an approval process?

Not before building, which reintroduces the queue people were escaping. Register what exists, classify by what it touches, and review the things that affect money, customers, or regulated data.

### What should people not build themselves?

Anything holding regulated or sensitive personal data without review, anything customer-facing, anything requiring an audit trail, and anything writing to a system of record without validation. Publish the list rather than refusing case by case.

### How do I get people to register what they build?

Make it take thirty seconds and give something in return — support, a backup, a shared connection. An inventory that only imposes obligations collects the compliant minority and misses everything else.

### What is the biggest practical risk?

Data access. An application built by somebody with broad permissions can reach far more than its purpose needs, usually because broad access was the easy configuration. Providing connections centrally is the most effective control.

### What happens when a tool becomes critical?

Have a known promotion path rather than an argument. Recognise the signals, involve the builder in the rebuild since they know the exceptions, and retire the original with a date so both do not run in parallel.

### How do I find what already exists?

Run a census: ask each team what they use, and check what the platforms themselves report. Voluntary registration is always incomplete, and the first census is invariably larger than anybody expected.

### How do I know the programme is working?

Count applications in active use rather than applications built, and count the requests that never reached engineering — that queue not forming is the benefit. Applications promoted to being properly built are a success signal, not a failure one.

### What should not be measured?

How many applications each person builds. It produces things nobody needed and makes the estate harder to govern in service of a number that describes activity rather than value.

### Can citizen development be stopped?

Not effectively. The demand is real and the alternative is doing the work by hand, so prohibition produces concealment rather than compliance — which leaves you with the same applications and no inventory of them.

## Related reading

- [Low-code platforms](/blog/what-is-a-low-code-platform)
- [No-code vs low-code](/blog/what-is-no-code-vs-low-code)
- [Automation hubs](/blog/what-is-an-automation-hub)