What Is a Citizen Developer? (We Are All Developers Now)

A citizen developer builds software for their own work, without a developer job title. It might be a CFO, an executive assistant, an investor or a company president. They build the tool because they know the job. They're also the ones who'll open it on Monday.

The term took off in the low-code years. IT teams handed business users drag-and-drop app builders and a list of rules. It stayed a niche.

That niche is about to cover almost everyone. I've watched presidents of companies, executive assistants and investors build their own tools. They pushed the code to GitHub and put it live on Vercel. They connected a Supabase database and onboarded their own teams. They got there by telling an AI coding agent what they wanted, in plain English.

We are all developers now. Most people haven't noticed yet.

What changed

The old citizen developer worked inside a low-code tool. You dragged boxes around a screen, and you hit the tool's limits fast.

Now you open Claude Code or Codex and describe what you want. It writes real code. You look at the result, say what's wrong, and it fixes it. You keep going until it works.

A few services then turn that code into something your team can open:

• GitHub stores the code and every version of it.
• Vercel puts it on the web, at an address your team can visit.
• Supabase gives it a database, so it remembers things between visits.

Claude Code walks you through each one, and it explains every step if you ask.

Who is building

Job titles tell you less and less about who builds.

The president of an 89-person energy company built a tool himself, next to his team. The whole company went through our program. The team shipped five tools worth at least $220,000 a year.

At a PE firm, the managing partner co-built a first-place tool in our competition. It screens executives, and it caught things a standard Google search missed.

A CEO I coach has his own GitHub repo, connected to Vercel. He's already picked the web addresses for a private dashboard and for his client presentations.

Each of them knew the work better than anyone they could have hired.

Why hiring someone to build from zero stops making sense

Think about the last time you hired someone to build a tool.

They came in cold. They tried to learn your business. You booked the calls, wrote the brief, explained it again, and waited. You paid for every hour they spent learning what your team already knew.

We wrote about the same problem with forward deployed engineers. A classic FDE spends months learning a business from zero. You pay for that learning curve every time.

The person who knows the work can now build the first version themselves. It's faster, and the tool fits, because the builder is the person who'll use it.

Outside help comes in later, at the last mile.

How it feels to ship your own tool

This is my favorite part of the work.

Someone ships a tool. A colleague opens it, tries it, and tells them it's great. The builder lights up. I've seen that moment in session after session.

That moment changes behavior. People who ship one tool start looking at every annoying task as the next build. That's why I call our program a behavior change program. Building becomes a habit, and habits spread through a team.

What a citizen developer still needs

Building the first version is the easy part now. Keeping it running is where tools die.

We've trained more than 2,500 people across 45+ cohorts. Our programs end with teams building real tools. Some go into daily use. Some sit frozen as prototypes. The frozen ones usually have nothing wrong with them. They're missing the last mile.

Before a tool your team built goes into daily use, check four things:

1. Data. What does it read, and is that data allowed in the tools you picked?
2. Security. Who can open it? A password on a dashboard is a start. Customer or financial data needs a proper review.
3. Ownership. Who fixes it when it breaks? Name one person.
4. A home. The code in GitHub, the app on a company account, the database backed up.

That list is the work a good engineer or an Operator in Residence does. It goes fast, because the tool, the users and the problem already exist.

How to become a citizen developer this week

1. Pick one task you know inside out. I keep a Post-it pad next to my desk. Every time something bores me, I write one line: "It sucks that I still have to do this manually." Start with one of those.
2. Describe it to Claude Code or Codex like you'd brief a new colleague. What goes in, what should come out, and what good looks like.
3. Build the smallest version that works. One screen. One job.
4. Put it in front of one colleague. Watch them try it. Take their feedback back to the agent.
5. Give it a home when it earns one. GitHub, Vercel, a database, and the four checks above.
6. Teach the next person. Show them what you built and how you built it. That's how it spreads.

Citizen developer FAQs

Is a citizen developer the same as a no-code user?

They overlap. A no-code user works inside one tool and its limits. Today's citizen developer describes what they want to an AI coding agent. It writes real code that can live anywhere.

Will citizen developers replace software engineers?

No. Engineers keep the hard problems: architecture, security, scale and the systems everything else runs on. Citizen developers take the small tools nobody ever had time to build.

Do I need to learn to code first?

No. You learn as you go. Ask Claude Code to explain what it just did, and read its reasoning. In our sessions, that's how people pick up the basics fastest.

Is it safe to let employees build their own tools?

It's safe with rules. Decide which data can go into which tools. Decide who reviews anything that touches customer or financial data, and who owns each tool. Our programs cover this early, before the big builds start.

How long does it take?

Your first small tool can take an afternoon. The habit takes longer. Our programs run 12 weeks. That's how long it takes for building to become part of the job.

Where to start

Your team already knows the work. That's the hard part, and they have it.

Pick one task. Build one tool. Put it in front of one colleague.

If you want to know where your team stands first, take the free AI Audit. It scores your readiness and shows you where to begin.