The RAPID process

This is the master definition of the RAPID lifecycle — the spine every playbook, standard and gate hangs off. It makes the deck's model operational: what each phase is for, when you may enter it, what it produces, and how it hands off to the next.

RAPID is a pipeline, then a loop: five phases run once (Definition → Design → Tech selection → Build → Refinement) to take a product from idea to first release, then the last two (Flow-state ⇄ Production) become a permanent loop that keeps improving it. The shape is pictured on The RAPID model; this page is the working definition of each phase — what it's for, when you may enter it, what it produces, and how it hands off.

Each phase transition is guarded by a gate — a checklist run in minutes, not a committee.

Two threads run through every phase

• Documentation + tests are created in Build and updated forever in Flow-state — the artefacts that compound.
• Security is woven through, not bolted on. "Production-ready" means production-ready and secure.

Neither is a phase; both are conditions every phase is held to.

Open the phase workspace

The lifecycle definition below explains the purpose, entry, work, output and handoff. When you are doing the work, keep the operational bundle beside it:

Phase	First operational artefacts	Gate
Definition	PFD · PFD rubric · first-draft prompt · PFD drafting skill	Definition of Ready
Design	UX flow · data model · screen spec · handoff pack	Design Review
Tech selection	Tech radar · tooling scorecard · ADR · stack playbook	Tech Selection sign-off
Build	Project scaffold · task-brief prompt · tests-from-ACs prompt	Merge gate
Refinement	Refactor-to-standard skill · security-review skill · test plan	Refinement Exit
Flow-state	Flow-state playbook · runbook · runbook-generation skill	Production Readiness
Production	Release evidence · incident comms · release-notes prompt	Production Readiness

The toolkit guide expands each bundle and shows maturity. Availability does not automatically mean an artefact is proven.

---

Phase 1 Definition

research → PFD

• Purpose: turn raw insight into an unambiguous, testable plan — the Product Feature Definition (PFD). Research-backed, not a vibe wishlist.
• Entry: a prioritised opportunity with a named Product Owner and access to the relevant SME(s).
• Key activities: AI-accelerated discovery and market/domain research (cited, confidence-rated); capture domain rules and edge cases with SMEs; write acceptance criteria concrete enough to generate tests from; state NFRs, compliance constraints and the commercial framing.
• Deliverable: a PFD — research synthesised into a plan.
• Exit gate: Definition of Ready.
• Handoff: the PFD, glossary and recorded SME sign-off pass to Design as a merge, not a meeting.

Phase 2 Design

flows · data · screens

• Purpose: give Build a complete, buildable design so agents never invent flows, data shapes or layout.
• Entry: Definition of Ready passed.
• Key activities: UX flows (text-first, repo-stored) → data model (with PII/sensitivity tagging) → key-screen specs mapped to design-system components → clickable prototype for SME validation.
• Deliverable: UX flows, a data model and key screens.
• Exit gate: Design Review.
• Handoff: the design handoff pack (flows, model, specs, component mapping, traceability), repo-stored.

Phase 3 Tech selection

stack + tools

• Purpose: choose the stack default-first from the radar and lock a reference architecture, so Build starts inside a known scaffold.
• Entry: Design Review passed.
• Key activities: default to the golden path unless there's a stated reason not to; time-boxed spikes; evaluate for agent-friendliness and UK+India skills; record the choice as an ADR and update the radar.
• Deliverable: a stack chosen + a reusable stack playbook (filled during Build).
• Exit gate: Tech Selection sign-off.

Phase 4 Build

everything + docs/tests

• Purpose: produce working software to standard — the director–builder loop in action.
• Entry: Tech Selection signed off; the RAPID project scaffold in place.
• Key activities: decompose the design into agent-sized tasks; run the loop (direct → agent builds → review at checkpoints → correct or accept); write docs and tests in the same PR as the code; security built in, not bolted on.
• Deliverable: working software, to standard, with docs & tests.
• Exit gate: the Merge gate on every PR; the Engineering Definition of Done on the build as a whole.

Phase 5 Refinement

acceptable → good

• Purpose: raise quality deliberately, as directed agent passes rather than open-ended polishing.
• Entry: the build is functionally complete and merge-gate green.
• Key activities: named passes as skills — performance, accessibility, resilience, observability, hotspot review — each with an exit bar.
• Deliverable: a tighter build — acceptable raised to good.
• Exit gate: Refinement Exit.

---

The loop

Phases 6 and 7 don't end — they alternate forever. Flow-state enhances; Production hardens and verifies.

Phase 6 Flow-state

friction → flow

• Purpose: make building itself faster — remove friction, add polish — and capture what's learned. The phase almost everyone leaves out; RAPID names it — and it is RAPID's flagship differentiator.
• Key activities: friction removal; keep docs and tests current; prune memory; add runbooks and gotchas.
• Deliverable: a polished build — friction removed — and capital deposited every loop (updated docs, tests, playbooks, memory) so the next turn starts faster than the last.
• Exit gate: Production Readiness — each release is verified here on its way into Production.

Phase 7 Production

secure · shipped · operable

• Purpose: ship safely and run reliably.
• Key activities: harden and verify; SLOs and alerting live; rollback tested; runbooks handed to Support; release comms.
• Deliverable: a live release — secure and operable.
• Entry gate: Production Readiness — passed on the way in from Flow-state. A production deploy is an irreversible action — a named human always authorises.
• Feedback: live signals return as new Definition input, so the cycle keeps improving.

---

Scaled variants

Because an agent does the execution, every phase is cheap — so rigour is no longer rationed to big bets. But cheap is not the same as ceremonial: scale the loop to the work.

Work item	How much process
New product / major feature	The full pipeline (1→5), then the loop.
Small feature / enhancement	A light pipeline — Definition and Design collapse to a short brief; Tech selection inherits the existing stack; straight into Build → Refinement → loop.
One-hour bugfix	Skip the pipeline; run a light loop — reproduce, fix through the Merge gate, verify in Production, and still deposit the gotcha and a regression test. Even a single bug earns the loop.

The rule: the gates never disappear, but the evidence they demand scales with risk. A bugfix's Merge gate still runs; it just has less to check.

The human's role

Across every phase, the human directs: sets the direction, makes the taste and trade-off calls, and authorises the irreversible. The agent investigates, builds, verifies, and captures what it learns. Execution moves to the agent; judgement and authority move up.