Skip to content

Operating model for worker-built apps

Use a federated operating model for a citizen developer program (as of October 2026). A small central enablement function owns the standards, the paved road and the app registry, while business teams build their apps and give first-line support. IT or engineering co-owns Critical apps, and managers sponsor builders and protect their time. If nobody owns this today, start with one named enablement lead, even part-time, and the 14-day starter.

Who this is for

IT managers, executives designing the program and enablement leads. You get the model, what each function does, where decision rights sit when several business units already build, and a decision record to adapt. Reading time: about 7 minutes.

What does a federated operating model look like?

Central standards and a thin platform, local delivery and first-line support, and a hand-over path to IT for the few apps that need it. This is written for a typical business: one with an IT function and some security capability. Public-sector sources point the same way: a community and shared standards, with delivery left in the business1, and IT maintaining only the apps that meet defined criteria.4

flowchart TB
    S[Executive sponsor:<br/>accepts Critical risk, settles escalations]
    M[Managers: sponsor and protect time]
    E[Enablement lead and champions:<br/>standards, paved road, registry, training]
    B[Builders and app owners<br/>in business teams:<br/>build, own, first-line support]
    R[Technical and security reviewers]
    I[IT / platform:<br/>approved tools, hosting, identity,<br/>co-owns Critical apps]
    C[Legal and privacy counsel:<br/>consulted]
    CO[Compliance owner:<br/>audit-scope apps]
    S --> E
    M --> B
    E --> B
    B -->|intake and review| R
    B -->|graduation| I
    E --> I
    C -.-> E
    CO -.-> E

The model rests on the risk tiers. The tier decides how much of each function an app needs, so most apps never meet the central team beyond intake.

What does each function do?

This section gives the shape. For who approves what, by tier, see the roles page; each function below has its full entry in the roles list.

Executive sponsor
The senior leader who backs the program, accepts residual risk for Critical apps and settles escalations.
Enablement
One named enablement lead plus champions. Owns the standards, the app registry, intake and triage, training and the builder community. It's a service that answers intake in days and never holds a queue builders must wait in. Training and champions are on enablement and training.
Platform
The IT/platform owner runs the approved-tools list, hosting patterns, identity and secrets. Start thin and add pieces when builders ask for them, because adoption follows value, not mandates.2
Security review and technical reviewers
The security reviewer handles Critical apps and security incidents. Technical reviewers (platform engineers, or trained champions on a published list) do the Important-tier technical check. Count their time when you plan the program. If review capacity can't keep up with demand, the model fails here first.
Data owners
Accountable for each data set. They sign off any app using Confidential or Restricted data, which keeps data decisions with the people who understand the data.
App owners
The business person accountable for an app in use, with a named successor. See app ownership and the support model for the first-line duties.
Managers
Sponsors of their builders. They agree the building time, approve intake for their staff's apps and name a new owner when someone leaves. In one survey, employees whose managers actively support AI were 1.7 times as likely to use it a few times a week or more, so give managers an explicit role.3
IT or engineering
Co-owns Critical apps after graduation. It doesn't support everything: support follows the tier.
Compliance owner (consulted)
Receives every app flagged as audit scope and sets its change-management and evidence requirements, at whatever tier the app is.
Legal and privacy counsel (consulted)
Answers the counsel gates, such as the jurisdiction flag and the consent gate, by the counsel route the enablement lead keeps open.

Don't: build a center of excellence that acts as a gate with a queue

A central team that every app must pass through, with a waiting line, drives builders back to unmanaged tools. Keep the central team small, make it a service and let the tier decide who reviews what. The failure also runs the other way: a federated model with no central owner has no one to keep the standards and the registry. One public policy shows the alternative to a gate: IT maintains only apps that meet defined triggers, not every app.4

Don't: adopt a single vendor's kit as your operating model

A vendor's governance toolkit shows capabilities worth copying, such as owner-leaves checks and inactivity notices. One widely used kit is documented as no longer actively maintained, so copy the capabilities, not the product.5

Don't: stand up the model with no technical-reviewer capacity

Important apps need a business review and a technical check. If nobody can do the technical check within days, apps wait or skip it. Name the reviewers and train them before you open intake.

What if nobody owns this today?

Name one enablement lead, even at a fraction of their week, then follow the 14-day and 30-day starter. Don't wait for a full team.

Depends on your circumstances (C7)

If several business units already build independently, settle decision rights before you add a central team. Central owns the standards, the registry, the approved-tools list and the tier definitions, so the same app gets the same tier everywhere. Units own their own intake answers, their app owners and their first-line support. Give each unit one named champion, and a shared forum where units trade what works. Disagreements on a tier go to the enablement lead, then the IT/platform owner, as the escalation path describes.

Where do training and community fit?

The role-based training tracks, champions with protected time and office hours are on the enablement page. To test them before opening to everyone, run a 90-day pilot program, starting from the pilot scope template.

Record the decision

Illustrative composite

Title: Operating model for worker-built apps · Status: proposed · Date: YYYY-MM-DD · Owner: IT manager (a role)

Context. Staff are building apps with AI, and no one owns standards, the registry or support.

Decision. Adopt a federated model: a named enablement lead and champions own standards, the registry and intake; business teams build and give first-line support; IT co-owns Critical apps; managers sponsor. Name technical reviewers before intake opens.

Alternatives considered. A central team builds everything (rejected: can't keep pace). A center of excellence as a gate (rejected: queues drive bypass). No owner (rejected: the status quo that produces orphaned apps).

Consequences. A named person has part of their week committed, and managers have a defined role. We review the model after the pilot and again each year.

Review by: six months from the date above.

Assumptions and evidence

  • A-024 (Low): we expect a named, funded builder community with champions to raise paved-road compliance more than mandates do. A pilot can only observe this; test it when you scale by phasing champion funding in unit by unit.
  • A-022 (Medium): we expect manager support to matter more than tool access. Test this in the pilot by training half the managers at the start and half at day 45, and comparing their teams' sustained use.
  • A-023 (Medium): we expect training to be needed for regular use. See enablement and training.

Evidence: government engineering blogs, vendor guidance and surveys. There is no independent, quantified post-mortem of an AI citizen-developer program. Facts on this page are as of October 2026.

  1. UK cross-government low-code community, "Celebrating one year of the cross-government low-code community" (2026-02-06): about 700 members, weekly sessions, shared standards and reuse. https://technology.blog.gov.uk/2026/02/06/celebrating-one-year-of-the-cross-government-low-code-community-a-people-first-approach [primary], accessed 2026-10-22. ↩

  2. CNCF TAG App Delivery, platform engineering maturity model (v1, Oct 2023): users choose platforms for the value they give. Written for developer platforms; the worker-builder case is an extension. https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/ [primary], accessed 2026-10-22. ↩

  3. Gallup, AI use at work indicator (data as of May 2026): employees whose managers actively support AI are "1.7x as likely to use AI a few times a week or more". https://www.gallup.com/699797/indicator-artificial-intelligence.aspx [survey], accessed 2026-10-22. ↩

  4. Government of Saskatchewan, low-code/no-code development and maintenance policy (May 2026), which keeps IT as maintainer only for defined triggers rather than every app. https://taskroom.saskatchewan.ca/-/media/project/taskroom/documents/policy/lowcodenocodedevelopmentandmaintenancepolicy.pdf [primary], accessed 2026-10-22. ↩↩

  5. Microsoft, "Tenant hygiene after setup" (CoE Starter Kit documentation, updated 2026-10-17), which states the kit is no longer actively maintained. https://learn.microsoft.com/en-us/power-platform/guidance/coe/after-setup-tenant-hygiene [vendor], accessed 2026-10-22. ↩