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). 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. 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