“A citizen-developer estate is a portfolio. Most leaders are happy to add positions and terrified to close one — which is exactly how a book turns into a liability.”
Why Citizen-Development ROI Matters Now
The first half of the citizen-development pitch is easy to say yes to: let every employee build the workflow they need, and stop routing trivial automation through a backlogged IT queue. Adoption confirms the appetite. Per Gartner’s CIO survey, 17% of organizations have already deployed AI agents and 42% plan to within a year. The flows, Copilot agents, and vibe-coded internal tools are multiplying whether or not anyone is keeping score.
The second half is the one nobody priced. Building is not the same as paying. An app that shipped is not an app that earns — it’s a position that has to be marked to market like any other. Some of those positions throw off real value. Many sit idle, consuming model tokens and license seats while holding live permission scopes against production data. And the market already knows how this ends: Gartner projects that over 40% of agentic AI projects will be canceled by the end of 2027, driven by escalating costs, unclear business value, and inadequate controls. The cancellations are coming. The only question is whether you choose them deliberately or discover them on an invoice.
| Metric | Figure | Source |
|---|---|---|
| Agentic AI projects canceled by end of 2027 | 40%+ | Gartner (2025) |
| CIOs who have deployed AI agents / plan to within a year | 17% / 42% | Gartner CIO survey |
| Average cost of a data breach | $4.88M | IBM Cost of a Data Breach 2024 |
| Value-at-stake Ospiri attributes to ungoverned agent exposure | +$670K | Ospiri published research |
A 40% cancellation rate is not a failure of the technology. It’s a failure to measure — to attribute value and cost at the position level so you can cut the losers before they cut you.
The Two Halves of the Equation
Most low-code governance programs are built entirely around the creation event — intake, provisioning, approval. That’s the front door. The exposure lives on the other side of it, in the lifecycle nobody instrumented.
| Dimension | The creation-side story (what gets measured) | The lifecycle-side reality (what doesn’t) |
|---|---|---|
| Business case | Projected savings on a one-page intake | Realized ROI 90 days after launch |
| Usage | “It launched” | Daily active use vs. dormant-but-permissioned |
| Cost | License at provisioning | Ongoing token spend, idle seats, maintenance |
| Risk | Risk tier at the gate | Drift — new directories, new data, new egress |
| Ownership | The employee who built it | Nobody, once they change teams |
| Exit | Not considered | No sunset path, no position limit |
Notice the pattern: every column that matters for ROI is on the right, and almost nothing on the right is being captured. You approved the trade. You never set up the P&L attribution.
The Anatomy of a Zero-ROI App
Idle apps don’t announce themselves. They go dark in a predictable sequence:
- Launch and a brief spike. The builder uses it, shares it with two teammates, logs a win in the intake tool. The business case is “closed.”
- The builder moves on. A reorg, a new role, a departure. The app keeps its OAuth scopes and its service-account keys. Ownership quietly becomes null.
- Usage decays, spend doesn’t. Daily actives fall to near zero, but scheduled jobs still fire, the agent still calls the model, and the license still renews. Cost is now fully decoupled from value.
- Drift sets in. A dependency updates, a connector’s permissions broaden, the app starts touching a directory it never touched at launch. Exposure rises while attention is at zero.
- It surfaces in an incident — or an audit. The first time anyone looks at the app again is when it appears in a breach timeline or a regulator’s data-flow question. By then it’s a mark-to-market loss the board never underwrote.
The danger isn’t the busy app. It’s the forgotten one that still holds the keys.
Scoring the Book: An App Value-at-Risk Score
You can’t prune what you can’t measure, and you can’t measure value with a binary “is it live.” Treat each app as a position with a continuous score that pairs realized value against carried risk:
App VaR = (Token + License Cost − Realized Value) + (Permission Scope × Drift)
The first term is the P&L. The second is the carried risk — the same frequency-times-severity logic a desk applies to a position. Roll it up per app, per team, per org.
| Factor | What it captures | Low | High |
|---|---|---|---|
| Realized value | Measured outcome vs. projected savings, 90 days post-launch | Documented, recurring | Unverified or zero |
| Token + license cost | Ongoing run-rate, not provisioning cost | Negligible | Idle but expensive |
| Permission scope | Sensitivity and breadth of data/systems reached | Local, low-sensitivity | NPI, PHI, production |
| Drift | Change in behavior since baseline | Stable | New directories, new egress |
An app that is cheap, well-used, and stable scores near zero — leave it alone. An app that is idle, expensive, broadly permissioned, and drifting is a loss position carrying tail risk. That’s the one you close.
The Penalty Box: Containment and Sunset as Architecture
Pruning a book is a discipline, not a one-time cleanup. The control you need is the ability to contain a misbehaving or zero-value app before it graduates to broad production — and to sunset it cleanly when the score says so.
| Control point | What it does | What it is not |
|---|---|---|
| Realized-ROI attribution | Ties run-rate cost and outcomes to each app continuously | A one-page business case at intake |
| Behavioral baseline + drift detection | Flags scope and egress changes at the kernel, where the action lands | A SaaS log that infers from API metadata after the fact |
| Penalty-box containment | Constrains a flagged app’s blast radius without ripping it out | Block-by-default, which kills adoption |
| Graceful sunset | Revokes scopes, archives, and documents the exit | Letting it run dormant with live keys |
This is the same reason monitoring alone doesn’t close the gap: a dashboard tells you an app drifted thirty seconds ago. Enforcement and observability at the kernel let you contain it while it’s mid-action and retire it on schedule. That distinction is the difference between agent observability and actual agent governance.
What CISOs and CFOs Should Do This Quarter
| Step | Action | Output | Effort |
|---|---|---|---|
| 1 | Inventory the live estate — every citizen app, its owner, its scopes | A real position list, not an intake log | Low |
| 2 | Attribute run-rate cost and realized value per app over 90 days | P&L by position | Medium |
| 3 | Score the book on the App VaR frame; flag idle-but-permissioned losers | A ranked prune list | Medium |
| 4 | Contain or sunset the bottom of the book; set position limits going forward | A pruned, governed estate | Medium |
The Bottom Line
Empowering everyone to build is only half the equation; the half that protects the enterprise is knowing which apps pay and retiring the ones that don’t. A citizen estate is a trading book, and a book you only add to is a book that eventually blows up — Gartner’s projected 40% cancellation rate is just the market closing those positions for you, on its schedule rather than yours. Measure realized ROI against carried risk, prune the losers before they drift into an incident, and you convert citizen development from an unhedged exposure into a managed portfolio. The willingness to cut a position is what separates a desk from a casualty.
If your team is sizing this for the next fiscal cycle, request a working session. We will walk through your live citizen-developer estate, build a realized-ROI-versus-carried-risk view of the book, and scope a containment-and-sunset deployment. First pass takes 90 minutes.