Citizen developers: How business teams became creative builders

Title tag: Citizen Developers: How Business Teams Build Apps | Webellian

Meta description: Gartner forecast that 80% of low-code tool users would work outside formal IT by 2026. See how citizen developers, low-code, AI, and governance are reshaping software delivery.

Citizen developers: How business teams became creative builders

In 2022, Gartner forecast that by 2026, developers outside formal IT departments would account for at least 80% of the user base for low-code development tools, up from 60% in 2021. The growth of AI-augmented low-code platforms is now lowering the technical barrier further, allowing business users to create workflows and internal applications with more natural-language assistance. Here is what is driving the shift and where it can fail.

What is a citizen developer, and why are they suddenly everywhere?

A citizen developer is a non-IT employee who builds business applications with IT-sanctioned low-code or no-code tools, and their numbers are growing because central IT cannot keep up with every request for software and automation.

Citizen development changes who is allowed to turn a business problem into working software.

Traditionally, a department that needed a new application, workflow, or automation submitted a request to IT. The request entered an IT backlog, competed with infrastructure, security, product, and maintenance work, and eventually reached a professional development team.

A citizen developer shortens that path.

They might be an operations manager, finance analyst, HR specialist, sales operations employee, or another domain expert who understands the process that needs improvement. Instead of writing a full application from scratch, they use low-code or no-code tools that abstract much of the underlying engineering.

The shift is partly a response to capacity constraints. A 2025 article published in IEEE Computer notes that demand for faster software solutions is exceeding the supply of skilled software developers, and identifies citizen development and generative AI as part of how organizations are responding to that gap.

More recent research shows that citizen development has moved much further into the enterprise mainstream. In Forrester’s 2025 Developer Survey, 89% of development executives said their organizations were either implementing or actively planning a citizen developer strategy. A separate 2025 KPMG survey of 2,170 companies found that 52% planned to use citizen developers for the majority of their low-code applications, while only 5% said they did not plan to use citizen developers in low-code development.

That does not make citizen developers substitutes for professional engineers.

The distinction is important:

Citizen developers typically solve smaller, well-defined problems inside their own teams.
Professional developers build and maintain complex systems where architecture, performance, security, scalability, testing, and long-term technical ownership require deeper engineering expertise.
IT teams still control the environment in which citizen development should happen, including approved platforms, access, security requirements, integrations, and governance.

Citizen development works because domain experts no longer have to translate every small operational problem into a formal software project.

The business user who understands exactly why an approval process wastes three hours each week can now build the first version of the solution directly.

That makes software creation faster. It also moves part of the responsibility for application development outside the traditional IT organization, which is why governance becomes as important as access to the tools.

What changed? How AI turned low-code into an everyday business skill

Low-code reduced the amount of technical knowledge required to build software, while AI is reducing it again by letting users describe an application or workflow in natural language instead of constructing every step manually.

The first generation of citizen development still required users to think like developers to some extent.

A low-code platform might replace source code with visual blocks, forms, connectors, workflow diagrams, and reusable components. That made development more accessible, but users still had to understand conditions, data relationships, events, and application logic.

No-code pushed abstraction further.

AI is changing the interface again.

Instead of configuring every element manually, a business user can increasingly describe the desired result in ordinary language. An AI-assisted tool can then generate an initial workflow, interface, formula, automation, or application structure.

The progression looks roughly like this:

Pro-code: write the logic directly.
Low-code: assemble much of the logic visually.
No-code: configure predefined behaviors with minimal technical logic.
AI-native low-code: describe the intended outcome and use AI to produce the first working draft.

This does not mean AI has made engineering irrelevant.

It means the starting line has moved.

The 2025 Stack Overflow Developer Survey found that 84% of respondents were using or planning to use AI tools in their development process, up from 76% in 2024. This shows how mainstream AI-assisted development has become among people who code, but it does not measure AI adoption among citizen developers specifically.

The business-user side is better supported separately. Gartner’s 2026 research on AI-augmented citizen development describes low-code platforms as shifting more application creation toward the business, while emphasizing the need for a shared, secure, and governed platform foundation.

Business users are therefore benefiting from two abstraction layers at once: the low-code platform hides much of the underlying technical complexity, while AI-assisted capabilities help translate natural-language intent into working logic.

This fits into the wider shift in how large language models are already changing enterprise workflows.

The result is not simply faster app creation. It is a larger potential population of builders.

A finance specialist no longer needs to understand traditional programming before creating a workflow. An operations manager may not even need to master every visual component of a low-code platform before producing a usable first version.

The old model was that IT builds everything and the business describes what it needs.

The emerging model is that IT governs the environment while the business builds more of what it already understands.

That shift can remove large amounts of routine work from the IT backlog. It can also produce many more applications than IT teams were previously responsible for monitoring.

What are business teams actually building?

Business teams are moving beyond simple forms and splitting into three practical builder roles: citizen developers create applications, citizen automators connect workflows, and citizen data scientists turn operational data into dashboards and models.

Citizen development is sometimes described as if every non-technical employee were becoming an application developer.

The reality is more varied.

Research by Barkin and Davenport cited in the source set separates grassroots technology builders into three useful categories.

Citizen developers: apps and automations

A citizen developer builds applications that solve a defined business problem.

Common examples include:

approval workflows;
digital forms;
internal request applications;
simple inventory tools;
departmental mini-CRMs;
employee onboarding tools;
lightweight case-management applications.

These tools often replace spreadsheets, emails, shared documents, or manual processes that have become difficult to manage.

The advantage is domain knowledge. The person building the tool may already understand the edge cases because they deal with the process every day.

Citizen automators: connecting the systems IT never got to

A citizen automator focuses less on building an application interface and more on removing repetitive work.

This can involve robotic process automation (RPA) or low-code automation that connects systems which were never properly integrated.

Examples include:

transferring information between applications;
generating recurring reports;
creating records after a form submission;
sending notifications based on business rules;
moving files between systems;
synchronizing departmental workflows.

A documented example comes from Deutsche Bahn, where a citizen-developed shift-log solution built with Power Apps and Power Automate reduced handwriting-related errors from 20% to 2% and saved shift managers approximately 70 minutes per shift, or around 24 hours per week across three daily shifts.

The example shows why citizen development can be valuable for operational problems that may be too narrow to justify a traditional software project but large enough to create meaningful cumulative savings.

Citizen data scientists: dashboards and models

The third group works primarily with data.

A citizen data scientist uses accessible analytics tools to build dashboards, visualizations, forecasts, or simpler analytical models without depending on a centralized data team for every request.

That might include:

sales dashboards;
operational performance reporting;
demand forecasts;
departmental KPI monitoring;
customer segmentation;
internal data exploration.

The common thread across all three groups is not the technology.

It is proximity to the problem.

Citizen developers, automators, and data specialists already understand the workflow, which allows them to test ideas quickly. The challenge is making sure speed does not create an uncontrolled parallel technology environment.

What is a fusion team, and why is IT still in the room?

A fusion team combines citizen developers, business technologists, and professional developers in the same delivery model, with citizen developers handling much of the routine build while IT retains responsibility for engineering standards, architecture, security, and governance.

Citizen development works poorly when it becomes a competition between business teams and IT.

The more sustainable model is collaboration.

Gartner uses the term fusion team for multidisciplinary teams that combine technology and business expertise around a shared outcome. Instead of handing a specification from one department to another, the people who understand the business process work directly with people who understand architecture, security, integration, and software delivery.

n a fusion-team model, citizen developers can handle contained, lower-risk business solutions, while professional developers focus on work that requires deeper engineering expertise, such as complex integrations, architecture, security, scalability, and business-critical systems.

A business technologist might build an approval workflow independently. A professional developer becomes involved when that workflow needs to integrate with a sensitive enterprise system, handle complex authentication, process large volumes of data, or become business-critical.

That creates clearer roles:

Citizen developers contribute domain knowledge and build contained solutions.
Business technologists bridge operational requirements and technology.
Professional developers handle complex engineering and integrations.
IT and security teams provide approved environments, architecture standards, access controls, and governance.

This type of cross-functional work is close to the delivery philosophy behind our Digital Factory team. Webellian’s main Digital Factory offering focuses on custom web and mobile development, while the broader service scope described through Webellian Asia also explicitly includes Low-code & AI Integration.

The model is therefore not “replace developers with business users.” It is to combine the right level of technical expertise with the people who understand the business problem.

That same principle appears in how clearly defined roles make cross-functional teams work. A team performs better when every participant has a distinct responsibility but works toward the same product outcome.

It also resembles the same collaboration principles applied to cloud migration, where technical work cannot be separated cleanly from communication, ownership, and continuous improvement.

Fusion teams give citizen development a structure. Business teams get more freedom to build, while IT stays involved in the places where professional engineering still matters.

What happens when citizen development goes wrong?

Citizen development becomes shadow IT when applications reach deployment without visibility, ownership, security review, or lifecycle control, while AI-generated code adds a separate risk because vulnerable logic can now be produced faster and by more people.

Building an application outside central IT is not automatically shadow IT.

The critical moment is deployment.

A citizen developer can experiment safely inside an approved environment. The risk changes when that application starts handling real business data, connecting to production systems, or serving other employees without entering the organization’s technology inventory.

That creates classic shadow IT.

Typical warning signs include:

no registered application owner;
no central inventory or app catalog;
undocumented data access;
unapproved integrations;
no security review;
no monitoring;
no retirement process;
credentials stored incorrectly;
applications that remain active after their creator changes roles.

Research from Red Access cited in the source material examined approximately 5,000 corporate applications built on AI coding platforms and found that about 40% exposed sensitive data without basic access controls.

That is an inventory and deployment governance problem.

AI introduces a second issue that should not be confused with shadow IT.

An application can be fully visible to IT and still contain insecure AI-generated code.

Veracode research cited in the brief found that 45% of AI-generated code introduced security vulnerabilities.

These are two separate risks:

Shadow IT risk: IT does not know the application exists or who owns it.
AI-generated code security risk: the application is known, but the generated logic itself contains weaknesses.

Treating both as the same problem leads to incomplete controls.

An application catalog can solve visibility. It cannot prove that generated code is secure.

A security scan can identify certain vulnerabilities. It cannot establish who owns an undocumented application or whether it should still be running.

Citizen development therefore needs controls at both levels.

Before deployment, organizations should know who owns the application, which systems and data it uses, whether the environment is approved, and how the application will be maintained.

Where AI contributes executable logic, the organization also needs appropriate testing and security validation.

The goal is not to prevent business users from experimenting.

It is to make sure the transition from “I built something useful” to “the company now depends on this” is visible and governed.

How do you govern citizen development without killing it?

Effective citizen development governance gives employees approved tools, templates, an application catalog, and clear guardrails so IT can control risk without manually reviewing every workflow or blocking business experimentation.

Over-govern citizen development and employees return to spreadsheets, manual processes, or unapproved tools.

Under-govern it and the organization gets shadow IT.

The useful middle ground is often described through Barkin’s 4 G’s:

Genesis: define why the citizen development program exists and which problems it should solve.
Guidance: teach employees what they can build, which tools are approved, and when professional IT should become involved.
Governance: establish ownership, security, data, compliance, and lifecycle requirements.
Guardrails: embed boundaries into the environment so safe behavior is easier than unsafe behavior.

This makes governance part of the platform rather than a document employees are expected to remember.

Practical governance guardrails can include:

an approved set of low-code and no-code tools;
reusable templates;
predefined connectors;
restricted access to sensitive data;
automated security checks;
an app catalog containing every deployed solution;
a named owner for each application;
a documented lifecycle;
an audit trail for important changes;
clear escalation criteria for professional developers.

The deploy step deserves particular attention.

Before a citizen-built application enters production, someone should be able to answer basic questions: Who owns it? Which data does it process? Which identities can access it? What happens when the owner leaves? How will security issues be discovered? When should the application be retired?

This is where how a professional development team structures that process can complement citizen development. Webellian’s Digital Factory primarily provides custom web and mobile development, while its wider service scope includes Low-code & AI Integration. The professional team does not need to build every departmental application, but it can help establish architecture and delivery boundaries.

The same principle appears in how agile teams typically structure delivery. Autonomy works best when responsibilities, feedback loops, and ownership are explicit.

Governance should therefore scale with risk.

A small internal workflow does not need the same process as an application processing customer financial data. Giving both the same approval process destroys the speed citizen development is supposed to create.

The objective is controlled self-service: let business teams build quickly inside known boundaries, then increase professional oversight as an application’s impact and risk increase.

Is this actually working? What the numbers say

Gartner forecast that low-code development tools would account for 75% of new application development by 2026, up from 40% in 2021. More recent enterprise survey data shows broad low-code adoption, although it does not measure the same metric: a 2025 survey of 2,000 enterprise technology leaders found that 98% of their organizations used low-code platforms, tools, or features somewhere in the development process.

Citizen development has moved beyond isolated departmental experimentation.

Several market indicators in the research point in the same direction.

Gartner figures cited across the source set include:

Gartner forecast that 75% of new application development would use low-code technologies by 2026, up from 40% in 2021;
developers outside formal IT departments were forecast to account for at least 80% of the user base for low-code development tools by 2026, up from 60% in 2021;
a low-code development market projected to reach approximately $58.2 billion by 2029, with a cited compound annual growth rate of 14.1%.

Those numbers show adoption. Named company examples help show what the model can produce operationally.

Wesco is one of the examples cited in the research. Its managed citizen development program reportedly generated around 100,000 hours of annual savings.

That scale matters because citizen development economics work differently from traditional enterprise software economics.

A company does not need every application to create millions of dollars in direct revenue.

A workflow that saves 15 minutes a day can be meaningful if hundreds of employees use it. An automation that removes several hours of repetitive work each week can justify itself even if it would never have ranked highly enough in the central IT backlog to become a formal software project.

Dentsu provides another example in the source set. Its citizen development program moved automation away from a centralized bottleneck and toward a broader organizational model.

The important word is “program.”

Successful citizen development is not simply the result of buying a low-code platform and giving everyone access. The examples described in the research combine wider building capability with governance, ownership, support, and organizational structure.

That distinction also helps explain why raw adoption figures should not be read as proof that professional development is disappearing.

More applications can be built because a much larger group of employees can address smaller problems directly. At the same time, enterprise systems, critical integrations, security architecture, scalable platforms, and technically complex products still require professional engineering.

The measurable benefit comes from matching the level of engineering to the level of the problem.

Is AI making citizen developers obsolete, or more powerful?

AI is not making citizen developers obsolete. It is removing more of the technical barrier to becoming one, which shifts the main constraint from the ability to build software to the ability to govern what gets built.

Low-code originally expanded software creation by reducing the need to write code.

AI expands it again by reducing the need to understand even some of the visual logic that low-code platforms previously required.

That means the population of potential citizen developers can grow rather than shrink.

The 2025 Stack Overflow Developer Survey found that 84% of respondents were using or planning to use AI tools in their development process, showing how mainstream AI-assisted development has become among people who code. Gartner’s earlier forecast that developers outside formal IT departments would account for at least 80% of the user base for low-code development tools by 2026 points to the broader expansion of software-building capabilities beyond traditional IT teams.

The interesting question is therefore not whether AI replaces low-code.

The two can reinforce each other.

An AI-native low-code environment can allow a user to describe an approval process, data workflow, or interface in natural language, generate an initial solution, and then adjust it through visual or conversational tools.

That changes the bottleneck.

Previously, the question was: Can this employee build the application?

Increasingly, the question becomes: Should this application exist, what can it access, who owns it, and how will the organization keep it secure?

The governance constraint becomes more important as the technical constraint becomes smaller.

AI can also increase the speed at which problems propagate. If an insecure pattern is generated and reused across several applications, organizations can create technical risk faster than before. This is why the security of AI-generated code and the visibility of citizen-built applications need separate controls.

The likely future is therefore not business teams replacing IT.

It is an environment where more people can create software, while professional IT becomes increasingly responsible for platforms, architecture, security, integration, standards, and governance.

The organization that benefits most will not be the one that allows the most people to build.

It will be the one that lets the right people build the right things inside boundaries that everyone understands.

FAQ

What is the citizen development framework?

A citizen development framework is the set of roles, tools, governance rules, and guardrails an organization uses to let non-IT employees build applications safely.

One useful model is Barkin’s 4 G’s: Genesis, Guidance, Governance, and Guardrails. Together, they define why the program exists, how citizen developers should work, which controls IT retains, and what technical boundaries apply.

Will AI replace low-code platforms?

No. AI is more likely to make low-code platforms easier to use.

Low-code already reduces the amount of traditional programming required. AI adds another abstraction layer by allowing users to describe desired workflows, interfaces, or logic in natural language.

The result is likely to be more citizen development, not less, with governance and security becoming increasingly important.

What is a fusion team?

A fusion team is a multidisciplinary team that combines business and technology expertise.

It can include citizen developers, business technologists, professional developers, security specialists, and other roles working on the same outcome. The business contributes domain knowledge and routine building capacity, while IT provides deeper engineering, integration, security, architecture, and governance.