Fictional demo with synthetic data, part of Tavor Ben Shahar's portfolio

Citizen Development Governance Model

The citizen development governance framework

How a tool moves from an employee's side project to something the organization can rely on, and who's accountable for it at each step.

The four stages

Idea

Someone has a plan for a tool or automation that solves a real, recurring problem. No working code yet, or only a rough sketch. Logging it here makes it visible instead of living only in one person's head or a chat thread.

Advances when: a working prototype exists, even a rough one.

Prototype

The tool works, at least in a limited way, and its builder (or a small group) is actually using it. Nothing depends on it yet, if it breaks, that's expected and fine.

Advances when: at least one person besides the original builder is using it regularly, and it hasn't caused a problem.

MVP

Multiple people rely on it for real work. It does the job, but has known gaps or rough edges the team has accepted for now.

Advances when: it's run reliably for a stretch without the original builder actively keeping it alive, and a maintaining team (not just the original builder) has been assigned.

Production

Fully adopted and documented. A team, not an individual, is accountable for keeping it running, independent of whether whoever originally built it is still around.

What triggers a stage change

Maintenance ownership

Every tool at MVP or Production has a maintaining team attached and visible on the tracker. That team owns keeping it running, they don't need to have built it originally, that's the whole point: ownership survives a departure.

What this framework doesn't do

This tracks ownership and maintenance signals, but it doesn't enforce anything. An organization that wanted hard gates (blocking a tool from advancing stages without sign-off) would need to layer that on top.