Skip to content

The worker-built app lifecycle

Every worker-built app, including automations and agents, moves through eight stages: idea, intake and triage, build, verify, deploy, operate and support, change, and retire. Each stage has a gate, and how deep the gate goes depends on the app's risk tier. Graduation to IT is a transition, not a ninth stage: it usually follows deployment, when a trigger fires, and an app that's Critical at intake plans it at intake and deploys on IT's platform. This page names each stage, says who's involved and links the one page that covers it.

The stages apply however the app was built; for the term most searchers use, see what vibe coding means for a business. This is the per-app spine. Rolling out the program across the business is the other spine, and it lives on the roadmap.

Who this is for

Builders, app owners, IT managers and reviewers who need the whole path on one screen. You'll get the stage order, the gate at each stage and where to read more. Reading time: about 5 minutes.

The eight stages at a glance

flowchart LR
    A[1. Idea] --> B[2. Intake and triage]
    B --> C[3. Build]
    C --> D[4. Verify]
    D --> E[5. Deploy]
    E --> F[6. Operate and support]
    F --> G[7. Change]
    G --> D
    F --> H[8. Retire]
    G --> H
    B -.-> X((Graduation to IT))
    E -.-> X
    F -.-> X
    G -.-> X

Solid arrows are the normal path. A change goes back through verify before it's released again. The dotted lines show where graduation starts: at intake for an app that's Critical from the start, or from any stage after deploy, whenever a trigger fires.

What happens at each stage, and where to read about it

The stages follow the same order as the builder's ten steps, so the lifecycle and the builder handbook never disagree. The builder handbook gives a builder the steps in order; this table shows where those steps sit in the app's life and who else is involved. For who does what at each gate, see the roles and decision rights page.

Stage What happens Who's involved Canonical page
1. Idea The builder works out what the tool should do, checks the data it would need, and starts in a private sandbox on approved tools Builder Builder handbook: start here and the data classes
2. Intake and triage Before sharing or widening data, reach or actions, the builder answers the six tier questions and gets a risk tier and an answer Builder, enablement lead (who runs intake and triage), data owner where needed Intake and approval
3. Build The builder writes a short spec, builds in small steps, writes test cases and documents the app Builder, champion Builder handbook, with spec, test and document
4. Verify Checks scaled to the tier: the self-check from Team up, then a business review and technical check, then independent tests and security review Builder, business reviewer, technical reviewer, security reviewer Verify before release
5. Deploy The app goes onto an approved hosting pattern with sign-in, private by default, and passes the go-live checklist before others rely on it Builder, app owner, platform or IT Hosting and make a vibe-coded app production ready
6. Operate and support The app runs, is monitored and backed up, gets support at its support level, and is reviewed on schedule App owner, backup, help desk, IT for Critical apps Run apps in production and the support model
7. Change Changes are made in small, reversible steps with tests run before and after; the tier questions are re-answered when users, data, reach or actions grow Builder or maintainer, app owner Change an app safely
8. Retire The app is shut down when its retire-by date passes, it's unused, its owner leaves with no successor, or it's replaced; its data and access are dealt with App owner, IT, records owner Retire an app
Graduation (planned at intake for an app that's Critical from the start; otherwise usually after deploy, when a trigger fires) IT or engineering becomes co-owner alongside the business app owner, checks readiness and decides to adopt, rebuild or retire App owner, IT or engineering Graduate to IT

There's no separate page for the idea, build, deploy or operate stages. Those jobs already have homes in the builder handbook, the platform pages and the operations pages, and a thin stage page would only repeat them.

Don't: skip retirement because the app still works

An app nobody owns can still be live, reachable and connected to company systems. That's AP19: orphaned apps (failure patterns).1 Set a retire-by date when the app is registered, and treat a missing owner as a trigger: name a successor, or start retirement, within a set time. Don't leave it running unowned. See when the builder leaves.

How gates scale with risk

Every worker-built app sits in one of four risk tiers (Sandbox, Team, Important or Critical), set by the highest answer to six questions about its data, users, internet reach, dependence, decisions about people and actions, and two floors apply at every tier. The tier sets how deep each gate goes: what registration, tests, review, hosting, support and documentation the app needs at each stage. That table lives in one place only, the gate matrix, and the stage pages link to their row of it rather than copying it.

The tier isn't fixed. Re-answer the six tier questions whenever the app gains users, data, reach, permissions or an AI feature, and at every scheduled review. A Sandbox app that a teammate starts using goes through intake before it's shared.

Don't: treat the lifecycle as a program rollout

These stages describe one app's life, and every app goes through them. Rolling the program out across the business (finding existing apps, piloting, scaling) is a separate plan with its own pages. Mixing the two hides the per-app gates inside a project timeline. See the roadmap for the rollout.

Agents and automations

Agents, scheduled jobs and automations follow the same eight stages as any other app. For them, the tier questions are answered for every permission the agent or automation has been granted, and its identity, grants and tokens are recorded in the registry and revoked at retirement. See MCP and agents.

Where the former frameworks went

Earlier versions of this site organized the lifecycle around eight acronym frameworks. Seven are now folded into the stage pages above, and the glossary's former framework names table shows where each one went. The one kept mnemonic, the builder's self-check, lives on verify before release.

See it in practice

The field guides follow illustrative composite apps through these stages, including an invoice-matching tool that moves from Sandbox to Important and an orphaned app that gets recovered and retired. To sort apps that already exist, run the risk tier workshop.

Assumptions and evidence

This page relies on no adoption assumptions of its own. The stage pages list the assumptions behind each gate.

Evidence: the lifecycle follows government guidance that the full lifecycle, including secure shutdown, should be managed,2 and standards that each map to stages from intake to operation.3 There are no controlled studies comparing lifecycle models for worker-built apps. Facts on this page are as of October 2026.

  1. OWASP Citizen Development Top 10, "CD-SEC-09: Asset Management Failures" [primary], https://owasp.github.io/www-project-citizen-development-top10-security-risks/content/2022/en/CD-SEC-09-Asset-Management-Failures, accessed 2026-10-21. Guidance from 2022; the orphan risk it describes persists. ↩

  2. UK Government, "Artificial Intelligence Playbook for the UK Government", 10 Feb 2025 [primary], https://www.gov.uk/government/publications/ai-playbook-for-the-uk-government/artificial-intelligence-playbook-for-the-uk-government-html, accessed 2026-10-21. ↩

  3. NIST, AI Risk Management Framework 1.0, Jan 2023, under revision as of October 2026 [primary], https://www.nist.gov/itl/ai-risk-management-framework, accessed 2026-10-21. Its Map, Measure and Manage functions line up loosely with intake, verify and operate. ↩