The Citizen Developer Myth: Why We Stopped Selling It

The Citizen Developer Myth: Why We Stopped Selling It

In 2022 we made a deliberate decision: stop offering citizen-developer programs to our clients. Even when they ask for one. That decision cost us revenue. It bought us something we value more, which is not having to clean up our own messes two years later. This article is the honest version of why.

The citizen developer pitch sits at the centre of most no-code marketing. Empower business users. Free your IT team. Let the people closest to the problem build the solution. It is a clean story. It also collapses, predictably, within eighteen months of any serious rollout.

We have now observed the same arc across more than forty client engagements. Months one through six are the honeymoon. Three or four motivated business users adopt the platform, build twenty or thirty workflows, and produce visible value. Leadership celebrates. The IT team feels relief. Vendors ask for a case study.

Months six through eighteen are the drift. The most active builder takes parental leave, gets promoted into a different role, or leaves the company. Half the workflows continue to run, often poorly. Nobody knows how to modify them. The IT team has not invested time learning the platform, because the platform was sold as something they did not need to learn. Operations teams find themselves dependent on automations they cannot explain.

Months eighteen and beyond are the audit. Someone, usually a new CIO or COO, asks the question nobody wanted to ask. What runs in this account? Who owns it? What breaks if it fails? In every audit we have run, the answers are uncomfortable.

Three reasons it fails

We see the same three patterns again and again.

The tool is not the bottleneck. Make, Zapier, n8n, and Power Platform reduce the cost of clicking a workflow together. They do not reduce the cost of thinking about edge cases, idempotency, error handling, or change management. A builder who has not seen what happens when a payload arrives malformed will produce a workflow that demos beautifully and fails silently in production. The platform cannot teach that. Experience teaches that.

Workflows are software, even when they are visual. Software needs maintenance, version control, tests, and monitoring. A business user spending two hours per week on automation does not have time for these disciplines. They are ignored until something breaks. Then they call the IT team, which has been deliberately kept at arm's length from the platform.

The career path is broken. A citizen developer creates value for the company but earns no specialization, no promotion, no recognizable skill on their CV. Those who become genuinely good leave the role, either by moving into engineering or by leaving the company entirely. What stays behind is workflows without owners.

What we recommend instead

We recommend a model we call the Automation Steward. It is a role, not a job title. One or two people, depending on company size, who have explicit time allocated for automation work as part of their job description. Minimum twenty percent of their working hours. Ideally more.

These people do not need to come from IT. They can come from operations, customer success, finance, or sales. What matters is that they have a real mandate. They can build workflows. They can refuse to build workflows. They can decommission old workflows. They control a tooling budget. They report regularly to leadership on what is running and what is broken.

This model concentrates knowledge. That carries its own risk: what if this person leaves? The risk is real, but smaller than the distributed citizen-developer alternative. A single steward can document, hand over, and train a replacement. A scattered group of part-time builders cannot. They produce ownership gaps by design.

Where citizen development still works

There is a narrow band where the original idea makes sense. In organizations with strong platform governance, clear documentation standards, an active platform owner, and a culture that rewards systematic work, citizen development can supplement a steward model. Not replace it. Supplement it.

The good use case is personal productivity. Mail templates, calendar shortcuts, small reminders, ad-hoc data exports. Workflows that touch only the individual's own data, do not modify shared records, and do not trigger customer-facing actions. Give people a sandbox for that, and many of them will build something useful.

The bad use case is anything that touches production data, external systems, or customer communication. Those workflows need ownership, monitoring, and lifecycle management. The vendor marketing implies a business user can handle all of this. In our experience, they don't. Not because they are not capable, but because they do not have the time, the mandate, or the career incentive.

Why vendors keep pushing the narrative

The platform vendors have a clear economic interest in the citizen-developer story. It widens the buyer pool from "IT team" to "everyone with a laptop". It simplifies the sales conversation by framing automation as something easy enough to be approached without specialist help.

We are partners with several of these vendors. We benefit when their licenses are sold. But we have audited too many accounts that started as citizen-developer programs and ended as forensic projects. The pattern is too consistent to ignore. We tell new clients this openly. Some hear it. Some build their citizen-developer program anyway, and call us back two years later to clean it up. We help them, for a fee. We would prefer to have prevented it.

A short summary

Citizen development was not a bad idea. It was an idea that overestimated one problem and underestimated another. It overestimated the IT bottleneck. In most organizations, IT is not the bottleneck for automation. It is the bottleneck for classical software projects. Automation platforms are far lighter. What is missing is rarely hands. What is missing is consistent thinking about maintenance and ownership.

It underestimated what building means. Building does not stop at "it works today". Building includes "I can still understand this in two years, and either maintain it or shut it down". Citizen developers, by structure, cannot meet that second standard. Not because they are not smart, but because they are not paid to.

Before launching a citizen-developer program, ask one question. In eighteen months, who is accountable for the workflows being built today? If the answer is "the people building them", the answer is wrong. Those people will not still be doing that work in eighteen months.

If the answer is "we do not know yet", the honest response is to not start the program until the answer is clear.

If you are not sure which model fits your organization, the free Automations Check is a useful first step. About thirty minutes of conversation usually surfaces the right next move.