April 9, 2026
You’ve turned 4,000 non-developers into builders. They’re solving their own problems. And now they’re all asking the same question — to which nobody has a clean answer.
The promise was simple: give people AI-powered tools, let them build solutions for their own teams, and watch productivity soar. And it worked. In large corporations, thousands of business colleagues are now building agents, automations, and small applications that solve real problems. The tool revolution has delivered.
But it has delivered something else, too — a question I now hear several times a week, and to which nobody has a satisfying answer:
“My prototype is running on my laptop. Where do I actually run it in production?”
This is the elephant in the room of the Citizen Development movement. We have become exceptionally good at enabling people to build. We haven’t kept pace with enabling them to deploy.
The Landscape Today
When someone asks me where their newly built system should run, the answers currently look something like this:
The Standard Answer: The Enterprise Cloud Platform
The established, enterprise-grade path. Robust, regulated, secure — and built for professional engineering teams with the skills and processes that this environment demands. For someone who has just built their first working agent, this feels like being handed the keys to a jumbo jet when all they really need is a bicycle.
The Near Future: Workflow Platforms like n8n
Low-code orchestration that bridges the gap between “it runs on my laptop” and “it runs somewhere real.” Standard pipelines, pre-built connectors, and a more accessible operating model. Promising — but still maturing when it comes to enterprise governance.
The Wildcard: Copilot Studio and Similar Platforms
Tightly integrated into the Microsoft ecosystem that many teams are already using. A potential path, but one that raises its own questions about flexibility, cost, and vendor lock-in.
None of these answers are wrong. But none are complete. And that is exactly the core problem.
It’s Not Just a Tooling Problem
The deeper you dive into this question, the clearer it becomes: the tooling question is actually three questions wearing a trench coat.
The Three-Layer Problem:
- Tools: Where does the code physically run, and how does it get there?
- Processes: What checks, reviews, and approvals are necessary — and are they designed for this new reality?
- Responsibility: Who operates this thing in production? Who gets woken up at 2 AM? Who patches the dependency when a security vulnerability is published?
An experienced colleague from Platform Engineering hit the nail on the head: this is a process and responsibility problem, not just a tooling problem. And he is right. A prototype that looks amazing on a laptop can be frighteningly fragile in production if no one has thought about security, staging, versioning, fault tolerance, resilience, and backups.
Voices from the Field
This is not an abstract concern. Here is what people in large enterprises are actually experiencing:
“We built an agent that automatically answers emails. It ran beautifully in the sandbox. Now we want to go into production — but that is significantly harder than building the agent itself. Five different departments have to run checks before anyone even looks at our system. Not all departments are prepared for us building solutions ourselves.”
“We urgently need contacts to act as guides and a protected space where anyone can develop solutions.”
These are not complaints. They are signals. The chasm between “I built something” and “it’s running in production” is so wide that many promising solutions simply die in the middle.
What Could the Answer Look Like?
From many conversations with colleagues, a vision has crystallized that deserves to be clearly articulated:
The Vision: Seamless Transition from Prototype to Production
Imagine a world where every self-developed solution starts in a sandbox with guardrails. When it is ready, you initiate an automated “production readiness check” — AI-assisted security scans, resilience checks, architecture validation — all centrally managed, but executed frictionlessly.
The exact same technology stack, the exact same patterns, every single time. The prototype becomes an enterprise deployment — not through the heroic efforts of individuals, but through a process explicitly designed for this exact moment.
This is not science fiction. It is an engineering problem with known building blocks: standardized container pipelines, integrated security scans, pre-configured monitoring, central governance rules implemented as automated checks instead of manual queues. The pieces exist. They just need to be assembled with Citizen Developers as the primary target audience — not just professional engineers.
Where Do We Go From Here?
No one has a finished answer yet. But the path forward has a few clear contours.
First: Control the guardrails centrally, not the tools. Security standards, operational requirements, and resilience guidelines should be codified as automated checks that every deployment path must pass — regardless of the platform behind it. Governance should be a gate, not a gatekeeper.
Second: Design the process for the new persona. Citizen Developers are not junior engineers. They are domain experts who happen to have built something. The production path must meet them where they are — not where the legacy software development process assumes them to be.
Third: Build community. Guides, open forums, shared patterns. The people building these solutions need each other — for troubleshooting, for encouragement, and for the collective pressure that drives organizational change.
The elephant in the room isn’t going anywhere. But at least we’re finally talking about it.