The four stages
In short
Every project moves through Design (shape, mocked data), Build (real backend on the Build Server), Rehearsal (dress rehearsal on the Rehearsal Server), and Live (production) — and each transition is a gate that checks readiness rather than a deploy button.
A project is always in exactly one stage. The stage decides what the agent may do, what infrastructure exists, and what a change costs.
| Stage | What it is for | Where it runs |
|---|---|---|
| Design | Architecture and frontend against mocked data | Nothing deployed |
| Build | Backend wired up end-to-end | Build Server |
| Rehearsal | Dress rehearsal: journeys, data migration, costs | Rehearsal Server |
| Live | Real users, real data | Live Server |
The environments are named after the stage they serve — Build Server, Rehearsal Server, Live Server — and Rehearsal and Live both run on real AWS infrastructure provisioned for your project.
Why stages instead of “deploy when ready”
Each stage removes a class of surprise before the next one can bite:
- Design settles what the app is while changing it is nearly free.
- Build proves it works end-to-end before anyone pays for production infrastructure.
- Rehearsal is where data migration, security posture, and running cost get walked through deliberately, on a copy — the drill nobody does when they go straight to production.
- Live is where the old system is retired and the new one takes over.
Gates
Moving forward runs a gate: a readiness check covering tests, health, architecture, and anything the stage requires. A gate can pass with warnings, and it can block. It is not a formality — it is the thing that makes going backwards rare.
Next: Design · Promoting between stages