Upcoming Workshop: Citizen Developer Agentic Software Factory on AWS
Register Here!People outside engineering can now describe an app and watch an AI agent build it. Massdriver is the layer that lets them do that inside your cloud, using only what your ops team has explicitly approved, so weekend projects never turn into incident reports.
Non-engineers are already shipping internal tools without opening a terminal. You can't stop it, but you can decide where it happens. Give them a paved road before they find a dirt one.
Some teams pay a premium just to get a safe-enough version of citizen development, on infrastructure they don't control and can't fully see into.
People run agents on their laptops with personal cloud creds, and ops finds out when the bill (or the breach) arrives.
Someone with an idea and no infrastructure background describes what they want in plain language to an AI coding agent. That's the entire interface. What's allowed, where it runs, and how it's secured all come from Massdriver.
Your platform team designs the modules (Terraform, OpenTofu, Helm) and the pre-provisioned resources: networks, accounts, registries, environments, the same way they already do for engineering. Then they grant a specific slice of that catalog to a citizen-developer group, maybe just one compute option and a couple of approved data stores.
When someone prompts their agent to build something, the agent queries Massdriver's context engine first to find out exactly what that group is allowed to use.
The builder never has to know what a Postgres instance is, let alone what to size it. The agent evaluates the approved options against the use case and picks the one that fits: a document store for one app, a relational database for another, all within what ops already blessed.
The agent doesn't invent a network or spin up a new cloud account. It uses the environment, network, and registry your ops team already built and shared, the same artifacts your engineering org's infrastructure runs on. A brand-new citizen-built app and a hardened production service end up governed by the same catalog.
A citizen developer describes an app in plain language to Massdriver Architect, a Claude Code plugin. Watch it pick Firestore for storage, deploy to Cloud Run, and run the OpenTofu and Checkov compliance checks ops already configured, the same infrastructure and guardrails your engineering org runs on.
This is the question every ops leader asks the moment they see a non-engineer ship something real, and it's the one most citizen-dev tooling doesn't answer. Every citizen-built app is stored as plain Terraform/OpenTofu and Helm in Massdriver's OCI registry. When engineering wants ownership, they pull the source into git, add a CI job, and it's theirs, same day.
Every module instance a citizen developer deploys shows up in the same registry view your platform team already uses, searchable by team, module, and environment.
Your platform team gets a single view of which teams, and which generated apps, are using the Firestore module, the Cloud Run template, or anything else you’ve shared across the org.
Delegating access also means keeping a live, queryable record of who used what, and where, so self-service never becomes a black box.
Most teams adopting this already have strong ops. What they lack is a safe lane for everyone who builds around the backlog.
A team of Ruby or Go engineers can ship application code all day without being compliance, security, or cost-scaling specialists, but the business still needs cloud, and someone still has to answer for what's running in it.
People with an idea and no engineering background who today either wait in a backlog or go find a tool that lets them skip the line. Citizen developers extend the same gap further out.
As citizen development catches on, the security of the cloud and the sanity of production ends up resting on ops's shoulders. Our job is to make this easy enough for a non-engineer to use, without making ops bolt on a whole new tool, or a new portal-shaped mess, just to grant it.
Most of the integration lives in an MCP server that any agent can query; a Claude Code plugin adds guardrails on top. Codex support is in progress.
Nothing to install: a Massdriver access token is the only credential needed.
Naming conventions for production resources, hard client-side blocks on touching prod, and a dev-release / test-grid flow for promoting something once it’s ready. Configured centrally, applied to every citizen-developer token automatically.
Ops decides exactly which modules and pre-provisioned resources each group can see. Expanding what a group can build takes one permissions change.
FAQ
No. They describe the app in plain language. The agent handles every infrastructure decision, strictly within what your ops team has already approved for that group.
The agent can only choose from modules and resources explicitly granted to its permission group. If it's not in the catalog for that group, it isn't an option, and there's no path around it.
Pull the source out of Massdriver's OCI registry, sync it to your normal git repo, add a CI job to sync changes back, and your engineering workflow takes over from there. Nothing needs to be rewritten to make that handoff.
No. A Massdriver personal access token is the only credential involved. Everything else is handled by the platform.
Claude Code today, through an MCP server and a Claude Code plugin. Codex support is in progress; new agents are additive since the MCP server is the integration surface.
No. Several teams using this have serious ops and platform functions already. The gap it closes is between engineers who aren't infrastructure specialists (and business users who aren't engineers at all) and the infrastructure decisions someone still has to make safely.
Self-host Massdriver and keep orchestration inside your security boundary, or let us run it for you.