An operations analyst builds a spreadsheet macro to automate a monthly reconciliation task that used to take two days. Three years later, that macro — now maintained by nobody in particular, understood fully by no one, and backed up nowhere reliable — is the system that finance, operations, and compliance all quietly depend on to close the books.
This is not a hypothetical. It is the default trajectory of unmanaged citizen development, and it happens in some form in almost every enterprise. Business users build solutions to real problems because IT cannot get to those problems fast enough. The instinct is not the problem. The absence of governance around it is.
Low-code and no-code platforms did not create citizen development — business users have been building their own tools with spreadsheets, Access databases, and macros for decades. What these platforms do is formalise the practice, making it visible, governable, and — done correctly — an asset rather than a liability.
What Low-Code/No-Code Actually Means
Low-code platforms provide a visual development environment with drag-and-drop components, pre-built connectors, and minimal hand-written code, aimed primarily at professional developers who want to build applications faster than traditional coding allows. No-code platforms go further, requiring no coding knowledge at all, aimed at business users solving specific, well-defined problems.
The distinction matters for governance, not just for marketing. Low-code platforms (OutSystems, Mendix, Microsoft Power Apps in its more advanced configuration) are typically deployed by IT or a hybrid IT/business team building departmental or enterprise-grade applications. No-code platforms (Power Apps canvas apps, Salesforce Flow, ServiceNow App Engine Studio at the citizen tier) are deployed directly by business users solving a problem in their own workflow.
Both matter. Enterprises that only invest in low-code for professional developers miss the productivity gain available from citizen development. Enterprises that allow unrestricted no-code adoption without governance rebuild the spreadsheet-macro problem at greater scale and with greater access to enterprise data.
The Citizen Developer and the Fusion Team
A citizen developer is a business user who builds applications using low-code or no-code tools, without being a professional software engineer and typically without reporting into the IT organisation. The most effective enterprise citizen development programmes do not treat citizen developers as a security risk to be contained — they treat them as a delivery capacity to be organised.
The organisational model that has proven most durable is the fusion team — a cross-functional group combining a business-domain citizen developer with a professional IT developer who provides architectural guidance, security review, and support for anything that needs to integrate with core systems or handle sensitive data. The citizen developer builds fast. The IT developer keeps what gets built inside the guardrails.
The Shadow IT Risk — and How Governance Actually Prevents It
Shadow IT is not new. What low-code platforms change is the blast radius: a business user with no engineering background can now build an application that reads from and writes to core enterprise systems, in an afternoon, without IT ever knowing it exists.
The governance failure mode is not "citizen development happened." It is "citizen development happened invisibly." The organisations that manage this risk well share four practices:
A managed platform, not a free-for-all. IT selects and provisions a small number of approved low-code/no-code platforms rather than allowing every SaaS tool with a "no-code automation" feature to proliferate independently. This is the single highest-leverage governance decision — it converts an unbounded problem into a bounded one.
Tiered governance by risk, not one-size-fits-all approval. A personal task tracker needs no review. An application that touches customer PII, financial transactions, or regulated data needs a security and architecture review before it goes into production, regardless of who built it or how simple the tool made it to build.
A visible application inventory. IT cannot govern what it cannot see. A central catalogue of citizen-built applications — what they do, what data they touch, who owns them, when they were last reviewed — is the foundation every other governance control depends on. Most low-code platform vendors now provide this natively as an admin capability; the failure mode is not enabling it.
A named business owner for every application, with a defined lifecycle. Every citizen-built application needs an accountable owner and a review cadence, exactly like any other enterprise system — otherwise it becomes exactly the unowned, undocumented dependency that spreadsheet macros were.
Vendor Landscape — Enterprise Low-Code/No-Code Platforms
| Platform | Model | Strength | Best for |
|---|---|---|---|
| Microsoft Power Apps | Low-code + no-code tiers | Deep Microsoft 365/Dynamics integration, Power Platform ecosystem | Microsoft-centric enterprises, broadest citizen developer reach |
| Salesforce (Flow, Lightning) | Low-code + no-code tiers | Native to the Salesforce data model and workflow | Organisations already running Salesforce as a system of record |
| OutSystems | Professional low-code | Enterprise-grade architecture, complex application support | Mission-critical applications requiring scale and governance rigour |
| ServiceNow App Engine Studio | Low-code + no-code tiers | Native to the ServiceNow workflow and ITSM data model | Organisations extending ServiceNow beyond ITSM into custom workflow apps |
Power Apps has the widest citizen-developer reach simply because of Microsoft 365 distribution — most enterprise employees already have access to it, whether IT has formally adopted it or not, which makes it the platform most likely to already be present as shadow IT and therefore the first governance conversation many IT leaders need to have. OutSystems remains the choice when a low-code build needs to scale into genuinely mission-critical territory rather than departmental convenience.
What to Do Next
Three questions that reveal citizen development maturity in any organisation:
1. Do you know how many business-critical processes currently depend on an application nobody in IT has reviewed? Most organisations genuinely do not know the answer, which is itself the finding.
2. Is there an approved, supported low-code/no-code platform available to business users today — or are they solving this problem with whatever SaaS tool they can access without asking? An unmet need for one does not disappear. It relocates somewhere less visible.
3. When a citizen-built application's creator leaves the organisation, does the application have a defined path to continuity — or does it become undocumented risk overnight? This single scenario, repeated enough times, is how "citizen development" becomes "technical debt" without anyone deciding it should.
The next post in this category covers Agile at Enterprise Scale — what changes when the practices that work for one team have to work for fifty.
