Foremy Software Insider Report — a weekly look inside the tools, deals, and decisions shaping the software industry.
The app nobody in IT knew existed
Every large organization now has a version of this story: a finance analyst, frustrated with a slow ticket queue for a simple internal tool, builds their own approval workflow using a no-code platform over a weekend. It works. Colleagues start using it. Six months later it’s processing a meaningful share of the department’s invoice approvals, nobody in IT has ever reviewed it, it has no documented owner besides the analyst who may or may not still be at the company, and it has direct write access to a financial system that would normally require months of security review to connect to.
This scenario — sometimes called “shadow IT,” increasingly rebranded more neutrally as “citizen development” — has moved from a minor governance footnote to a genuine boardroom-level tension in 2026, and the debate over how to handle it is splitting organizations into two camps with very different bets on the future of enterprise software.
The case for embracing citizen development
Proponents — often product and operations leaders rather than IT leaders — make a case that’s hard to dismiss: the people closest to a business problem usually understand it better than a central IT team juggling a hundred competing priorities. No-code and low-code platforms, especially now supercharged by AI assistance that can turn a plain-language description into a working application, let those people solve their own problems in days instead of waiting months for a ticket to work its way through a backlog.
The economic argument is straightforward too: central IT and engineering teams are expensive and perpetually oversubscribed. Every internal tool built by a business team without engineering involvement is, in theory, engineering capacity freed up for higher-leverage work that actually requires custom software engineering.
The case for tighter control
IT and security leaders counter with a list of real, recurring problems they encounter cleaning up after citizen-developed tools:
- No ownership continuity. The person who built the tool leaves the company or changes roles, and the tool keeps running with no one who understands how it works or can fix it when it breaks.
- Uncontrolled data access. No-code platforms often connect to core business systems with broad permissions because narrowly scoping access requires technical expertise the builder doesn’t have — creating exactly the kind of over-permissioned access pattern that security teams spend enormous effort trying to eliminate elsewhere.
- Compliance blind spots. A citizen-built tool processing customer data, financial transactions, or HR information may fall squarely within regulatory scope — data residency rules, financial controls, privacy regulations — without anyone involved in building it realizing that’s the case.
- Duplicated, conflicting logic. Multiple departments independently build slightly different versions of similar workflows, leading to inconsistent business logic across the organization that nobody has reconciled.
“I’m not against citizen development. I’m against citizen development with zero visibility. Those are different problems, and most organizations are actually fighting the second one while telling themselves they’re fighting the first.” — an enterprise architect at a healthcare technology company
The AI acceleration factor
What’s changed the shape of this debate specifically in the past year is the arrival of AI-assisted app-building tools that lower the skill barrier even further than traditional drag-and-drop no-code platforms already had. Where building a functional internal tool once required at least some familiarity with the specific no-code platform’s logic and interface conventions, a growing category of tools now lets a non-technical employee describe what they want in plain language and get a working application, complete with a database and basic logic, in minutes.
This is a genuine productivity unlock, and it’s also a genuine acceleration of every risk IT and security teams already worried about with traditional no-code platforms — because the barrier to creating a new, ungoverned tool with access to sensitive systems has dropped even further, while the organizational processes for discovering, reviewing, and governing those tools have not kept pace at all.
What governance actually looks like at organizations getting this right
Rather than choosing a binary “allow” or “ban” stance, the organizations that insiders describe as handling this well tend to converge on a similar middle path, built around a few concrete practices:
A sanctioned platform, not a free-for-all
Instead of allowing any no-code or AI app-building tool anyone wants, IT teams designate one or two approved platforms with pre-configured, appropriately scoped connections to core business systems — so citizen developers get real building freedom, but within guardrails that were set up correctly once, centrally, rather than improvised individually across dozens of departments.
A lightweight registration requirement
Any tool that touches customer data, financial systems, or more than a small number of users gets registered in a central inventory with a named owner — not because every tool needs a full security review, but because the organization needs to actually know what exists before it can make risk decisions about it.
Tiered review based on actual risk, not blanket policy
A tool that helps a five-person team track internal task assignments doesn’t need the same scrutiny as a tool that touches payment data or personally identifiable customer information. The most effective governance models we’ve seen this year explicitly tier their review requirements by the sensitivity of the data and systems involved, rather than applying a single one-size-fits-all approval process that ends up either too slow for low-risk tools or too loose for high-risk ones.
A designated “graduation” path
When a citizen-built tool becomes genuinely business-critical — handling significant transaction volume, supporting a large user base, or touching regulated data — the best-run organizations have an explicit process for engineering to take formal ownership, rebuild the risky parts on more robust infrastructure if needed, and relieve the original business-team builder of ongoing maintenance responsibility they were never equipped to carry long-term.
The talent question underneath it all
There’s also a longer-term workforce implication that gets less attention than the governance debate: as citizen development becomes more normalized, the line between “technical” and “non-technical” roles is blurring in ways that job descriptions, hiring processes, and career ladders haven’t caught up to. A finance analyst who has effectively been building and maintaining production business logic for two years, even through a no-code interface, has developed a meaningfully different — and more valuable — skill set than their job title suggests. Forward-looking HR and people leaders are starting to ask whether performance reviews, promotion criteria, and internal mobility paths should formally recognize this kind of hybrid technical fluency, rather than treating it as an unofficial hobby that happens to be useful.
What to watch next
- Whether no-code and AI app-building platform vendors build more robust native governance and audit features directly into their products, reducing the burden on IT teams to build oversight processes from scratch.
- Whether regulators in data-sensitive industries (healthcare, financial services) issue more explicit guidance treating citizen-developed applications as subject to the same compliance obligations as traditionally engineered software.
- Whether “AI app builder sprawl” becomes enough of a recognized risk category that cyber-insurance underwriters start asking about it directly during policy renewal, the way they now routinely ask about cloud configuration and endpoint protection.
A quick insider Q&A
Q: What’s the biggest myth about citizen development that IT leaders still believe?
A: That banning unsanctioned tools actually stops the behavior. Enterprise architects consistently report that outright bans just push the activity further underground — employees use personal accounts, personal devices, or platforms IT has never heard of, which is strictly worse for visibility than a sanctioned platform with appropriate guardrails.
Q: How should a business team decide whether their project needs IT involvement at all?
A: The clearest heuristic we heard repeatedly: if the tool will touch customer data, financial systems, or more than roughly a handful of users outside the immediate team, involve IT early rather than asking forgiveness later. Purely internal, single-team productivity tools with no sensitive data are generally treated as lower priority for formal review.
Q: Are AI app-building platforms themselves becoming a security product category?
A: Increasingly, yes. Several platform vendors in this space are racing to add built-in governance features — permission scoping, usage auditing, automatic data-sensitivity detection — directly into their products, partly in response to enterprise customer demand and partly as a competitive differentiator against rivals still treating governance as an afterthought.
A cultural note
Beyond the technical governance question, several operations leaders pointed to a less tangible but equally important factor: how citizen development is talked about internally shapes whether it gets reported or hidden. Organizations that frame IT’s role as a helpful partner — “come talk to us and we’ll help you build this safely and quickly” — report far higher voluntary disclosure of citizen-built tools than organizations where IT is perceived primarily as a gatekeeper whose main function is saying no. That perception, more than any specific policy document, appears to be the deciding factor in whether shadow IT actually stays hidden or surfaces early enough to manage.
The bottom line
Citizen development isn’t a fad and it isn’t going away — the economic and speed incentives behind it are too strong, and AI tooling is only making it easier. The organizations winning this particular internal battle aren’t the ones that banned it outright or the ones that ignored it entirely. They’re the ones that treated it as a governance design problem to be solved deliberately, rather than a trend to either resist or passively tolerate.
Foremy’s Software Insider Report publishes weekly analysis on the tools, deals, and decisions shaping enterprise and developer software. Have a tip or an inside perspective to share? Reach the team at team@foremy.com.