The rise of the citizen developer

Last year’s winter break was a turning point for agentic coding. Anthropic released Opus 4.5 in late November, and over a quiet couple of weeks a lot of people discovered that Claude Code could now do real work. One engineering leader told us their CEO, who isn’t an engineer, came back from Christmas announcing that the backlog was done! Technology leaders returned in January with excitement and a sense of competitive urgency: their teams needed to adopt these tools or risk falling behind.

The tools quickly found an audience beyond engineering: people in finance, operations, sales, and product building software for the jobs they already have. These citizen developers know the work, and they’re the first user of what they build so they can iterate quickly and build useful tools. A product manager at a large tech company built a dashboard on their laptop showing how each of the team’s experiments moved the funnel. Nobody would have funded it as a project, but it was so useful it became a key part of how the team ran.

Over six weeks this fall we held more than 50 research conversations with citizen developers and the people who support them. We kept hearing versions of the same story: someone builds a tool that works on their laptop, colleagues want to use it, and over time it takes on more credentials, data, and dependents than its creator can look after. The technology leaders we spoke to want to unlock the productivity that only citizen developers can deliver, but they’re missing the governance frameworks and tools to adequately support them.

Sharing is where the exposure starts

Building has become the easy part. Sharing is harder: we heard about tools passed around as zip files with instructions for running them, dashboards emailed every week as HTML files built from a local snapshot, and shared artifacts that half a team couldn’t open. When people do find a way to publish, it’s often the quickest one at hand: a personal cloud account, or a hosting service paid for with a personal credit card. Once colleagues use a tool, it reads data and acts on their behalf, usually with credentials that belong to its creator, and it may now be reachable from the public internet.

Every tool borrows someone’s credentials

A tool that reads company data has to sign in as someone, and on a laptop that someone is usually the person who built it. We heard about personal API tokens wired into dashboards, service accounts that worked half the time, and a product manager who lent a personal key for a web-scraping service to the director of marketing. The director’s work with it stopped the day the subscription was cancelled. A revenue operations leader asked: when a colleague runs my tool, whose permissions is it using?

Useful tools turn into dependencies

That exposure grows with usefulness, because useful tools attract people who rely on them, usually faster than anyone planned. A product manager’s experiment dashboard became critical to how the team worked. Engineering eventually put two or three people on a parallel rebuild for about three months, and the product manager kept using the original until the week before we spoke. At another company, a platform leader described a quality dashboard whose data would stop updating if its creator went on holiday, and a cost dashboard that refreshed only when someone pressed a button on their laptop.

Teaching citizen developers to be engineers doesn’t work

The obvious response is to bring citizen developers into the engineering process, and companies have tried. One ran Git classes for its non-engineers and described the result as a disaster. Another gave its marketing lead an isolated copy of the customer intake form, a staging environment, and a coding-agent skill written just for her. She still declined to make changes because she was worried she’d break something customers depended on. A platform leader told us that if you ask people to do much in a terminal, they won’t.

Governance built into a paved road

Security teams already have a blunt form of governance. A CISO told us their endpoint monitoring could block these tools, but blocking stayed off for fear of breaking business processes that already depended on them.

The companies furthest along have built a paved road instead. One platform team set up internal hosting, and about half the company’s employees have now deployed an app. If an app’s security score drops below a threshold, its owner has two weeks to fix it, and the fix arrives as a prompt for their coding agent. Rules like this are set once by security and operations and applied to every tool, with no review queue in front of each one. They run inside the company’s own network, where its sign-in, network rules, and data commitments already apply.

Running a paved road takes people. One company staffs its platform with four or five engineers and a support channel; at another, a single engineer built it and nobody clearly owns it. Whether a company builds its road or buys one, the program that put coding agents in everyone’s hands has to fund the governance and operations that come with them.

A governance checklist for the tools you already have

You don’t need a platform to start. Find one tool people rely on by asking which reports, dashboards, or automations someone would miss if they stopped for a week, since a scan won’t find the ones on laptops. Then sit down with the person who made it.

1. Whose credentials does it use? Replace personal tokens with credentials the company issues, scopes to the job, and can revoke without breaking the tool.
2. What data does it read, where does that data go, and what can it change? Keep company data inside accounts the company controls, and add validation or human approval before the tool changes business records.
3. Where does it run, and who can reach it? Move it behind company sign-in and off the public internet, somewhere colleagues can use it while its creator is on holiday.
4. Who owns it, and who helps when an update breaks it? They may be different people. Write down both names.
5. What does it depend on? When the next advisory arrives, you should be able to list the affected tools and confirm they’ve been updated.
6. Does it still need to exist? Retiring a tool that has done its job is a good outcome.

Doing this for one tool will show you what your citizen developers need from IT and security, and what a paved road at your company would have to include.

Why we’re building Valet

This research shapes our work on Valet. Valet is the app platform enabling citizen development in enterprise. Valet gives your platform and AI enablement engineers the tools to guide citizen development, govern the software outputs, enforce policies, and automate the operations and maintenance so that these tools can become critical to your business.