Delivery Crew

Case study

The problem

Turning a rough stakeholder ask into a plan the whole team can actually build from normally costs a string of meetings and handoffs — a PM writes a spec, an architect designs against it days later, frontend and backend build against the architecture from memory of a conversation, and QA writes tests against whatever the acceptance criteria happened to say weeks earlier. Context degrades at every handoff, and the gap between what was promised and what actually got built is usually caught late — in QA if the team is disciplined, in production if it isn't. Nobody sits down and re-reads the original acceptance criteria against the actual implementation plan before code gets written; there usually isn't time.

The solution

Every request goes through the same eight roles in a real dependency order — Product Owner, then Architect, then Frontend, Backend, and Security in parallel off the same architecture, then QA, then DevOps, then a Delivery Lead who synthesizes all seven into one brief. Each role reads the actual structured output of everything it depends on, not a summary — the Frontend and Backend plans reference the exact API surface the Architect defined, and QA's test plan is built directly against the Backend and Security plans it was handed. QA carries one job none of the other roles do: re-read the Product Owner's original acceptance criteria against what Frontend, Backend, and Security actually planned, and name anything not really covered. A human can send any completed stage back with feedback, which marks that stage and everything downstream as needing a re-run without silently regenerating the whole pipeline and spending API calls on parts that didn't need to change.

How it was built

The provider is a real per-role, per-request configuration choice, not a hardcoded client — a thin dispatch layer routes each role to Anthropic or OpenAI depending on what was chosen when the request was created, both going through the same Zod-validated structured-output contract. This was tested for real, not just wired up: one full eight-stage run had the Frontend role on OpenAI's GPT-5.5 while every other role ran on Claude Opus 4.8, and the OpenAI-generated frontend plan correctly referenced the exact endpoints the Anthropic-generated architecture had defined, confirming cross-provider context genuinely flows rather than each call operating in isolation. The QA-closes-the-loop design proved itself on the same run: the team had been asked for "a CSV export," but the architecture had evolved into a ZIP of five separate files, and QA flagged that literal mismatch against the original acceptance criteria — independently, the Delivery Lead's synthesis caught the same gap and correctly refused to call the plan ready to ship. The revision system deliberately keeps a stale stage's last output visible instead of clearing it, and deliberately does not auto-regenerate downstream stages when an upstream one changes — a human decides how far a revision actually needs to ripple, which is also just cheaper than re-running seven model calls every time one assumption changes. Frontend, Backend, and Security are genuinely parallel in the dependency graph but run as sequential calls in practice, a plain tradeoff against concurrent writes to a single SQLite file rather than a claim that the pipeline itself is sequential.

Gallery

The problem

The solution

How it was built

More projects

Margin Trader

Scopecraft

AI Support Workflow Optimization