We've watched too many engagements stall under pure waterfall or sprawl under pure agile. The pattern that ships consistently — and that we run on every Source Code engagement — is a four-phase model with hard acceptance gates between every phase: Discover → Design → Deliver → Optimize.
01 — Discover (1–2 weeks)
Before any code is written: stakeholder interviews, current-state mapping, KPI baselines, value-driver workshop. The output is a signed alignment artefact — what we're doing, why it matters, and what success looks like. No phase 2 without sign-off.
02 — Design (2–3 weeks)
Solution architecture, integration design, sprint plan, RACI. We lock the plan before the build sprint starts — not because plans don't change, but because a baseline lets us measure when they do. Gate criterion: blueprint signed by sponsor and tech lead.
03 — Deliver (4–12 weeks)
Build, test, train, roll out. Bi-weekly demos against working software, not slides. Feature flags everywhere so we can ship daily without scary release days. Gate criterion: UAT pass and pilot acceptance form signed.
04 — Optimize (ongoing, quarterly cycles)
After go-live the work doesn't end — it shifts. Quarterly tuning sprints, KPI tracking against the discovery baseline, debt registry. The platform keeps earning long after launch.
Why gates beat sprints
Pure agile without gates lets scope sprawl and accountability blur. Waterfall surfaces problems too late. The gate-based model gives the buyer a clean exit point at any acceptance — you walk away with a working artefact, not a stalled project — while giving the seller a clean payment milestone. Both sides win when the bar is concrete.
Every payment is gated by a signed acceptance form. No ambiguity, no "is this done?" debates. That's the discipline that makes the model work.