No-Code and Low-Code: The Citizen Developer Myth

At some point in the last five years, almost every enterprise software vendor added a "no-code" tier to their product. Microsoft Power Platform, Salesforce Flow, ServiceNow App Engine, Appian, Mendix. The pitch is consistent across all of them: your business users, your operations managers, your HR analysts, people without software development training, can now build the applications and automations their teams need without waiting months for IT to prioritize a ticket. This is democratization of software development. The citizen developer has arrived.

I do not think the pitch is entirely wrong. There are genuinely useful things that non-technical users can do with these platforms that they could not do five years ago. A manager can build a form that routes approvals. A team can set up a notification automation that triggers when a status field changes. A data analyst can build a simple dashboard without writing code. These are real improvements, and for that class of task, no-code tools work.

The problem is the ceiling. The more complex the use case, the more it becomes clear that "no-code" describes the entry point, not the eventual working state of anything serious.

The first ceiling is data modeling. When a citizen developer starts building an application that touches enterprise data, they quickly encounter questions that require understanding data models, relationships between tables, and how the platform represents those relationships. The visual interface handles simple cases. It does not handle cases where you need to understand database normalization, or where the data is split across multiple systems with different formats, or where you need to write a query that filters records by conditions the drag-and-drop interface was not designed for. At that point, the platform's visual tools run out, and the citizen developer either simplifies the use case in ways that make it less useful, or they start needing help from someone who understands systems architecture.

The second ceiling is security. Enterprise data has access controls, role-based permissions, audit trails, compliance requirements. A citizen developer building an app that pulls customer data, financial records, or HR information is making decisions about who can see what, even if they do not realize that is what they are doing. The default settings on most no-code platforms are not designed with enterprise security postures in mind. IT then inherits the security problem from an application they did not build and often did not know existed until something went wrong.

The third ceiling is integration. Real enterprise use cases almost always involve connecting to systems that have APIs, authentication requirements, data transformation needs, and rate limits. The platform's built-in connectors handle the simple, well-documented cases. When the use case requires a custom integration, or when the target system's API does not have a pre-built connector, the citizen developer is writing code again, just in a different context, or they are back to asking IT.

What tends to happen in practice is that an organization deploys a no-code or low-code platform, encourages widespread adoption, and generates a large number of small applications built by different teams with no coordination. Some of those applications use production data. Some have been shared across departments. Some were built for a workflow that has since changed, but the application is still running. None of them have documentation. None of them have a designated owner who knows how they work. IT did not build any of them and may not even know most of them exist.

This is, as I described in the post about workarounds and shadow IT, shadow IT with a nicer interface. The difference between someone building a rogue Excel workflow in 2010 and someone building a rogue Power App in 2025 is mostly cosmetic from a governance standpoint. The organization still ends up with applications that represent real business logic, that real employees depend on, that nobody owns, and that are harder to audit, modify, or decommission than a properly managed IT asset.

I think the most honest framing of citizen developer platforms is this: they lower the floor for genuinely simple use cases and they provide real value there. But the marketing overclaims what happens above that floor. The phrase "citizen developer" implies that someone without technical training can build production-grade applications. The word "developer" is doing a lot of work in that phrase. Development at any real level of complexity requires understanding data, security, performance, and maintainability. No-code tools do not eliminate those requirements. They hide them from view until the first time they matter.

The governance problem is not unique to no-code platforms, but no-code platforms amplify it by reducing friction at the creation stage without reducing friction at the maintenance and accountability stage. Creating something is fast. Figuring out who owns it, what data it touches, what happens when the vendor updates the platform and the application breaks, those questions are as hard as they ever were.

My read is that organizations get the most out of these platforms when they treat them as tools for IT-enabled business users rather than tools for replacing IT. That means establishing naming conventions, data governance rules, and ownership requirements from the start, even for simple applications. It means IT knowing what is being built, even if IT did not build it. And it means being honest about which use cases genuinely do not require developer expertise versus which ones are going to need engineering support eventually, because the latter category is larger than most rollout plans assume.