Business teams no longer need an engineering backlog to build software.
A finance analyst can create an approval workflow in Power Apps. An operations manager can connect customer data to an automation platform. A marketing team can generate an internal dashboard with AI-assisted coding. A regional business unit can build a small application around spreadsheets, APIs, and SaaS connectors without involving central engineering.
For enterprise technology leaders, the problem is not that employees are building these applications. The problem begins when those applications quietly become operational dependencies.
The scale makes visibility difficult. CIO Dive, citing Torii’s 2026 SaaS Benchmark Report, reported that the average large enterprise operates 2,191 applications. At the same time, AI-assisted development is making it easier for employees to create workflows and applications outside traditional engineering processes.
The engineering question has therefore changed. Enterprises do not simply need a citizen development policy. They need a technical operating model for discovering, auditing, monitoring, supporting, and, when necessary, rebuilding software created outside professional engineering teams.
How can enterprises find applications that IT does not know exist?
The first audit problem is discovery.
A central application catalog rarely captures everything employees have built. A departmental app might live inside Microsoft Power Platform, Airtable, Retool, Zapier, Google Apps Script, a cloud account, an AI coding environment, or even a personal SaaS workspace connected to corporate systems.
Dashlane reported in 2026 that unmanaged SaaS and AI tools continue to create significant visibility gaps, with employees frequently adopting applications outside centralized identity and procurement processes.
Engineering teams therefore need to build an inventory from multiple telemetry sources rather than asking business units to self-report everything.
Useful discovery signals include identity provider logs, OAuth consent records, API gateway traffic, DNS and proxy logs, cloud billing accounts, corporate card transactions, Git repositories, browser extensions, SaaS administration consoles, low-code platform environments, email registration patterns, and secrets discovered in enterprise credential stores.
Each discovered application should receive an owner, business sponsor, technical contact, user count, data classification, authentication method, external integrations, deployment environment, and business criticality rating.
The important field is not simply “who built it?” It is “what stops working if this application disappears tomorrow?”
A small tool used by five people may still trigger customer refunds, modify pricing data, approve transactions, or move regulated information between systems. Business impact, not user count, should determine audit priority.
What should engineering teams audit inside a citizen-built application?
A technical audit should treat the application as production software, even if its creator does not consider it software.
Gartner noted in its 2025 research on low-code governance that organizations need governance mechanisms that allow citizen developers to create applications quickly while maintaining quality, security, and supportability.
The review should begin with identity and authorization. Engineering teams should determine whether authentication uses enterprise SSO, whether role-based access control exists, whether privileged operations are separated, and whether terminated employees can automatically lose access through SCIM or equivalent provisioning.
Next comes data flow.
Teams should identify every system the application reads from and writes to. API tokens, spreadsheets, databases, CRM systems, customer records, LLM providers, document repositories, and third-party connectors should appear on a simple dependency map. Sensitive information should have documented retention, encryption, residency, and deletion rules.
The application itself also needs engineering review. Teams should inspect generated code where available, third-party packages, API permissions, hard-coded secrets, error handling, input validation, logging, dependency versions, backup processes, and recovery procedures.
For AI-generated applications, prompts are not the only risk. Generated code may introduce vulnerable libraries, weak authorization logic, unrestricted database queries, exposed API keys, or dependencies that nobody inside the organization understands well enough to maintain.
Which controls should exist before an employee-built app becomes business critical?
The point of governance should not be to send every small internal workflow through enterprise architecture review. That would recreate the bottleneck citizen development was supposed to remove.
Controls should increase with risk.
An isolated workflow that converts spreadsheet formats needs fewer controls than an application that writes customer records into Salesforce or initiates financial transactions.
Once an application crosses a defined risk threshold, engineering should require production standards such as source control, automated backups, separate development and production environments, centrally managed secrets, enterprise authentication, approved API connectors, dependency scanning, change history, rollback procedures, and a named production owner.
Applications handling customer, employee, financial, health, authentication, or proprietary data should face additional security and compliance review.
This matters increasingly as AI enters employee-built systems. IBM’s 2025 Cost of a Data Breach research found that 63 percent of breached organizations either lacked an AI governance policy or were still developing one. Organizations with high levels of shadow AI experienced breach costs averaging $670,000 more than organizations with little or no shadow AI.
The goal should therefore be controlled self-service. Employees can continue solving problems locally, but applications that gain operational importance progressively inherit enterprise engineering controls.
How should these applications be monitored after they enter production?
Auditing an application once does not make it safe indefinitely.
Citizen-built applications change quickly because their creators are usually close to the business process. A workflow that initially reads one spreadsheet may eventually connect to a customer database, an AI model, an ERP API, and an external messaging platform.
Monitoring needs to capture both application health and governance drift.
Runtime errors, latency, failed automations, API failures, authentication failures, unusual data transfers, privileged actions, dependency changes, and unexpected usage increases should feed existing observability or SIEM platforms where practical.
Platform teams should also monitor configuration changes. A new OAuth permission or database connector may change an application’s risk profile without changing its visible user experience.
Third-party exposure deserves particular attention. Verizon’s 2025 Data Breach Investigations Report found that third parties were involved in 30 percent of breaches studied, while credential abuse and vulnerability exploitation remained leading initial access vectors.
This makes connector governance, credentials, API permissions, and dependency inventories as important as conventional application monitoring.
The enterprise application register should therefore behave like a living control plane, not a spreadsheet reviewed once a year.
When should an enterprise rebuild rather than continue governing the original app?
Some citizen-built applications should remain exactly where they are.
Others outgrow their architecture.
Common warning signs include rapidly increasing user counts, customer-facing functionality, sensitive data processing, revenue dependency, complex integrations, repeated outages, manual deployment steps, unclear ownership, performance problems, or regulatory requirements the original platform was never designed to support.
At that stage, the question becomes whether engineering should harden the existing application, migrate it to a governed low-code architecture, or rebuild parts of it using conventional software engineering.
The original workflow still has value. It has already validated the business requirement.
Engineering should preserve that domain knowledge while replacing fragile infrastructure around it. This approach usually produces better results than either banning the application or forcing teams to start requirements discovery again from zero.
Which consulting companies can help enterprises audit and productionize these applications?
Enterprises that have accumulated dozens or hundreds of departmental applications may use external engineering partners to accelerate discovery, architecture assessment, remediation, and modernization. Several firms operate in this broader area:
- Deloitte has published guidance specifically addressing citizen development governance, including supportability, security, scalability, interoperability, and assessment of nonfunctional requirements. Its approach can fit organizations looking at citizen development as part of a wider transformation and governance program.
- Accenture combines low-code engineering with architecture, DevOps, application lifecycle management, data loss prevention, security, and platform governance. Its Power Platform engineering roles, for example, explicitly cover managed deployment pipelines, security controls, DLP, integration patterns, and application supportability.
- GeekyAnts approaches the problem more from the product engineering and modernization side. Its current engineering practice includes architecture reviews, security assessments, code-quality audits, DevOps, CI/CD, cloud monitoring, and taking prototypes or lightly engineered applications toward production-grade systems. That can be relevant when a citizen-built application has already demonstrated business value but now requires deeper engineering intervention rather than additional low-code configuration.
The appropriate partner depends largely on whether the enterprise needs governance design, platform-specific controls, or hands-on engineering to rebuild and operate individual applications.
What should technology leaders do before citizen development scales further?
The wrong response to employee-built software is usually prohibition. Employees adopted these tools because they were solving real operational problems faster than central technology teams could reach them.
The better response is to make risk visible.
Technology leaders need to know which applications exist, what data they touch, who owns them, what happens when they fail, how they authenticate, which third parties they trust, and when their risk profile requires professional engineering ownership.
Once that foundation exists, citizen development can remain a source of speed without becoming an uncontrolled second application estate.
For organizations already dealing with hundreds of departmental workflows, AI-generated tools, and low-code applications, a useful starting point is a focused architecture and governance assessment. A working session that maps the highest-risk applications, their dependencies, ownership gaps, and production-readiness issues can usually reveal where governance alone is sufficient and where modernization should begin.
Add Comment