Citizen Development Failed Three Times. Here's What's Different Now.
Spreadsheets, low-code, and RPA all tried to let non-engineers build software—and all stalled on the same flaw. The fourth attempt removes it.
Citizen development—the idea that the people closest to a problem should build their own software—has failed three separate times, and each failure had the same root cause. Spreadsheets, low-code platforms, and robotic process automation all decentralized the act of building successfully. Every one of them then fragmented the org’s data and governance, because each tool produced its own isolated silo of logic, access, and information that nothing else could see or trust. The idea was never wrong. The architecture was. What’s different now is that the building can finally land on one shared, governed foundation—and produce real software, not another island.
That distinction is the whole story. For forty years, “let non-engineers build” meant “let non-engineers create another thing leadership can’t account for.” Remove that, and the idea that failed three times becomes the operating model that wins.
TL;DR
- Citizen development has been tried three times—spreadsheets, low-code, and RPA—and each wave decentralized building but fragmented governance, leaving the org with more capability and less visibility.
- The recurring flaw was never that employees can’t build; it’s that every tool became its own silo of data and access that no other system could see, audit, or trust.
- Spreadsheets proved anyone can model a process, but they lacked any backend, controls, or oversight—the same gap that produced famous, costly real-world errors.
- Low-code raised the ceiling but locked each app inside one vendor’s walled platform, so the apps couldn’t share data or identity with anything outside it.
- RPA automated work by scripting bots on top of systems no one unified, and a large share of projects stalled before they ever scaled.
- The reflex answer today—handing every employee an AI coding assistant like Copilot or Cursor—targets the wrong layer, because those tools assume engineering skill and operate on code, not on the org’s shared foundation.
- What finally changes the outcome is architectural: building on one governed substrate that produces real full-stack apps, so distribution stops costing the org its ability to see itself.
Why has citizen development failed three times?
Each wave correctly diagnosed the bottleneck and then rebuilt the same trap. The bottleneck is real and permanent: there will never be enough professional engineers to serve every internal request, and the person closest to the problem understands it better than any developer assigned a ticket about it. So three times, the industry handed building tools to non-engineers. Citizen development is exactly that—someone whose job title isn’t “engineer,” a finance analyst or an ops lead or an HR partner, builds working software to solve a problem they own instead of filing a request and waiting two quarters. The promise is fit and speed: the tool matches the work because the person who does the work made it.
The failure mode is always the same. Each new tool gave one person their solution and gave the org one more thing it couldn’t see. The work got faster; the company got blinder—the same dynamic that makes shadow IT fundamentally a visibility problem rather than a discipline one. Eventually the accumulated governance cost—untracked data, unmanaged access, undocumented logic—outran the productivity gain, leadership recentralized, and the cycle reset. Three waves, one flaw.
What did spreadsheets get right and wrong?
Spreadsheets were the first and most successful citizen-development tool ever shipped, and they proved the core thesis beyond argument: hand a non-engineer a grid and a formula bar, and they will model their entire job in it—budgets, pipelines, inventory, headcount plans. No procurement, no ticket, no engineer. The fit was perfect because the builder and the user were the same person.
The flaw was that a spreadsheet has no backend, no access control, no audit trail, and no separation between data and logic. It is a single file one person owns and everyone else copies—and that gap is load-bearing. The Reinhart-Rogoff case is the canonical example: two Harvard economists’ influential 2010 debt-and-growth paper rested on an Excel formula that failed to select the full row, silently omitting five of twenty countries. A graduate student found it three years later; correcting it flipped the headline result from −0.1% growth to +2.2%—after the original number had already been cited to justify austerity policy across multiple governments.
That’s a diagnosis, not an indictment. A tool with zero governance scales its errors as fast as its usefulness. Multiply one untracked file across a 400-person company and the org runs on logic nobody can inspect.
Why didn’t low-code and RPA fix it?
Low-code platforms were the second wave, and they fixed the spreadsheet’s missing backend. They gave non-engineers a real database, forms, and workflow logic behind a drag-and-drop canvas. The ceiling rose: you could build something closer to an actual application without writing much code.
But low-code traded one silo for a nicer-looking one. Each app lived inside a single vendor’s walled platform, speaking that vendor’s proprietary data model. An app built on one low-code platform couldn’t natively see the data in an app built on another, or in the company’s core systems, without custom integration work that defeated the point. The org accumulated a portfolio of small platforms, each a separate world with its own login, its own data, its own export problem.
Robotic process automation—the third wave—gave up on unification entirely. Since your systems don’t talk to each other, RPA scripts a bot to click through the screens a human would, moving data between tools by imitating a user. It’s automation layered on top of fragmentation rather than a fix for it, and brittle by construction: any UI change breaks the bot, and the bots multiply faster than anyone can govern them. The pattern shows in the outcomes—EY’s “Get ready for robots” report found that as many as 30 to 50% of initial RPA projects fail, and most that survive never scale past a handful of bots.
Three tools, three architectures, one identical result: the building decentralized, the seeing fragmented.
The three waves: what each got right, and why it stalled
The pattern is easier to see side by side. Each wave solved the previous wave’s most visible gap and reproduced the deeper flaw underneath it.
| Wave | What it got right | The silo it created | Why it stalled |
|---|---|---|---|
| Spreadsheets | Anyone can model their own process | A file with no backend, access control, or audit trail | Errors and data scale invisibly; nothing is governable |
| Low-code platforms | Real database and logic, no waiting on IT | An app locked inside one vendor’s proprietary platform | Apps can’t see each other or the org’s core systems |
| RPA | Automated repetitive work across existing tools | A brittle bot scripted on top of unconnected systems | Breaks on any UI change; rarely scales past a few bots |
| AI coding assistants | Real code, fast, for people who can already code | A repo a non-engineer can’t read, review, or operate | Wrong layer for non-engineers—relocates the barrier |
The fourth row is today’s reflex, and it deserves the same fair reading as the others.
Isn’t handing everyone an AI coding assistant the answer now?
It’s the obvious move, and it’s the wrong layer. Faced with the same old bottleneck and a new wave of capable AI, most orgs reach for AI coding assistants—Claude Code, Cursor, GitHub Copilot—and hand them to everyone, expecting non-engineers to build. These are genuinely excellent tools. For engineers.
That’s the catch. A coding assistant operates at the code layer: it edits files in a project you already own and assumes you can read what it produces, run it locally, review the diff, and ship it through an engineering pipeline. Point that at a finance analyst and you haven’t removed the barrier—you’ve relocated it. The assistant made an engineer faster; it didn’t make a non-engineer a builder. It’s the fourth tool in the same pattern: real capability aimed at the wrong layer for the person holding it, producing yet another artifact—a repository—the org can’t easily see or govern.
So the question that matters isn’t “which AI tool do we hand people?” It’s “what do people build on?” Get that wrong and the fourth wave fails the way the first three did.
What’s structurally different this time?
One coffee. One working app.
You bring the idea. Remy manages the project.
The flaw in all four cases reduces to two failures that traveled together: each tool was a new silo, and—except for code assistants—none produced real, full-stack software. Fix only one and you get the historical result. Fix both and the idea finally holds.
That requires building to land on one shared, governed foundation: same identity system, same data layer, same logs, same deployment path for everything anyone builds—the substrate IT owns once it becomes a platform team instead of a ticket queue. When the foundation is shared, distributing the building no longer fragments the seeing. A finance analyst ships a tracker; it inherits the org’s auth, its data sits where leadership can query it, its activity shows up in the same logs as everything else. The analyst gets speed. The org keeps its map. That’s the move spreadsheets, low-code, and RPA each made impossible by design—because each one was the silo.
This was a fantasy for forty years because building anything real on a shared foundation still required engineers—the exact bottleneck the whole exercise was trying to route around. Non-engineer speed or real, governed software, never both.
What removes both flaws at once
A new category of AI tool—the product agent—removes both flaws in a single move. A product agent lets someone describe an application in plain language and get back a real, deployed full-stack app: backend, database, authentication, frontend, and deployment. Not a spreadsheet, not a walled low-code app, not a brittle bot, and not a repository only an engineer can operate. Today the most advanced one is Remy.
Here’s why it ends the forty-year pattern. Unlike coding agents such as Cursor or Claude Code—which edit code in a project you already own and assume engineering skill—a product agent works at the product layer: you describe what you need, it drafts a plain-language plan, and that plan compiles into a working app with real server-side auth, real data, and a live URL. The plan is the source of truth, so changing the app means editing the plan and recompiling—not hand-maintaining code a non-engineer can’t read. A typical full-stack build runs roughly $30–40 in inference. That’s the “real software” half of the fix.
The other half is the substrate. Because a product agent compiles every app onto the same governed foundation, the apps your teams build aren’t a hundred new islands—they share identity, data, and logs by construction. That’s the exact failure spreadsheets, low-code, and RPA never escaped, removed at the root. Distribution and visibility stop being opposites, which is the premise of what the winning org looks like: everyone builds, and leadership still sees the whole board.
An honest boundary: this is early. Product agents are in open alpha, and enterprise needs like SSO and SAML aren’t there yet. But the structural thing that doomed three prior waves—silos, and the absence of real software—is what a product agent on a shared stack is built to remove. For the category itself, what a product agent is goes deeper.
FAQ
What is citizen development? Citizen development is when people who aren’t professional engineers—finance analysts, ops leads, HR partners—build working software to solve problems they own, instead of filing a request to a central IT or engineering queue. The appeal is fit and speed: the person who does the work builds the tool.
Why has citizen development failed before? It failed three times—spreadsheets, low-code, and RPA—not because the idea was wrong, but because each tool decentralized building while fragmenting governance. Every app became an isolated silo of data and access the org couldn’t see, until the governance cost outran the productivity gain.
What’s the difference between low-code and a product agent? Low-code builds apps inside one vendor’s proprietary platform, so each app is walled off from other systems. A product agent compiles a plain-language plan into a real full-stack app on a shared, governed foundation, so the apps share identity, data, and logs rather than becoming separate islands.
Can’t we just give everyone an AI coding assistant? Assistants like Copilot, Cursor, and Claude Code are excellent for engineers, but they operate at the code layer and assume you can read, review, and ship code. Handing them to non-engineers relocates the barrier instead of removing it, and produces a repository the org still can’t easily govern.
What makes the current wave structurally different? Past waves fixed one problem at a time—low-code added a backend but kept the silo. The current shift fixes both flaws at once: building lands on one shared, governed substrate and produces real full-stack software, so distribution no longer costs the org its visibility.
Is this safe enough for enterprise use today? Product agents are in open alpha and don’t yet support SSO or SAML, so they fit internal tools and prototypes more than regulated enterprise rollouts right now. The architectural point is that auth and roles are enforced server-side in the compiled backend, on a foundation leadership can observe.
The bottom line
Citizen development didn’t fail because non-engineers can’t build—they proved they can, three times over. It failed because every tool that let them build also handed the org another silo, and most of those tools never produced real software in the first place. Spreadsheets, low-code, RPA, and now the reflex of handing everyone a coding assistant all stumble on some version of those two flaws. The fourth attempt is different only because it removes both: real full-stack apps, compiled onto one governed substrate, where distributing the building no longer fragments the seeing.
If you want to see what building on one shared substrate actually looks like, explore Remy →.
