Delivery Loop
How Catalyst projects make progress — one cycle at a time.
Read this when planning work, deciding when to advance, or explaining the process to stakeholders.
Useful for anyone running or participating in delivery cycles.
Why This Matters
Projects fail when they build too much before getting feedback. The delivery loop keeps you aligned by forcing regular checkpoints — so you catch problems early and validate direction continuously.
One cycle = one pass through the loop. Most features take multiple cycles. Each cycle makes the work clearer, more validated, and closer to done.
The Four Phases
Every delivery cycle follows the same rhythm:
Brief
Define what and why. Capture scope, goals, and constraints so everyone — including AI — knows the target.
Build
Make something real. With AI, you can often have a working prototype in hours, not weeks.
Review
Show it to stakeholders. Gather reactions and agree together on what works and what to change.
Refine
Apply feedback and decide. Loop back to Brief for another pass, or promote to the next stage.
How Long Is a Cycle?
Short. Hours to days, not weeks. The goal is fast feedback, not perfect output.
| Stage | Duration | Rhythm |
|---|---|---|
| POC | 2–4 hours | Quick proof cycles. Show something real fast. |
| MVP | 1–2 days | Feature cycles. Build, show, learn, repeat. |
| MMP | 2–5 days | Hardening cycles. Design system, edge cases. |
| PROD | 2–5 days | Controlled cycles. Testing, monitoring, rollback. |
Phase Checkpoints
Each phase has a natural checkpoint — a question to answer before moving on:
| Phase | Checkpoint Question | Ready When... |
|---|---|---|
| Brief | "Is intent clear enough to build?" | You can explain what you're building in one sentence |
| Build | "Is it ready to show?" | The core flow works and won't crash when clicked |
| Review | "Do we know what to change?" | Feedback is captured and prioritised |
| Refine | "Loop again, or advance?" | Brief is updated with learnings, next step is clear |
When to Advance
Advancing to the next stage is a deliberate decision. Most cycles loop back to Brief.
- Core functionality is validated by stakeholders
- Quality expectations for current stage are met
- Team agrees the work is solid enough to harden
- Next stage requirements are understood
- Major feedback hasn't been addressed
- Core flows are still unstable
- Stakeholders are requesting significant changes
- Quality doesn't meet stage expectations
Advancing too early is the #1 cause of rework. Run another cycle if you're unsure. The cost of one more cycle is much lower than hardening work that needs to change.
Delivery by Stage
What 'good delivery' looks like changes as you advance:
| Stage | Focus | Cycle Rhythm | Quality Bar |
|---|---|---|---|
| POC | Speed over polish | Many short cycles. Fail fast. | Happy path only. Rough is fine. |
| MVP | Validation over features | Longer cycles. Real feedback. | Auth, persistence, error handling. |
| MMP | Polish and reliability | Careful cycles. Edge cases. | Performance, security, a11y. |
| PROD | Stability and observability | Controlled cycles. Testing. | SLAs, backups, incident response. |
Delivery isn't a straight line. It's a loop you run many times, advancing only when the work is validated. The loop is the mechanism for building the right thing — not just building something.
Next Steps
Ready to dive deeper? Pick a path: