StudioApr 25, 2026 · 4 min read
How we run a four-week build sprint
The exact cadence (discover, design, build, launch) and the rituals that keep it honest. What we do in each week, and why.
Wren ItoStudio Producer, SUE
Four weeks is short enough to force decisions and long enough to actually ship. Here is the shape of the sprint we run for most engagements.
Week 1. Discover
Goals, audience, existing analytics, an audit of what is there today. We end the week with a one-page brief that everyone signs off on. If the brief takes longer than a week, the project is too big.
Week 2. Design
Design system in code, key pages prototyped live in the browser. Client review happens on a URL, not in Figma. By Friday, the design system covers 80% of the site's surface area.
Week 3. Build
Composable frontend wired to the CMS, deploy previews per PR. Content team starts filling the site in parallel. QA rides along, not at the end.
Week 4. Launch
Perf pass, cross-device QA, DNS, monitoring, launch. Then a clean handoff, including a runbook for the on-call engineer we will never be.
A short calendar is a design tool. It closes doors that were not worth opening.
Wren Ito
Runs project rituals at SUE, from kickoff to launch. Writes about the parts of a build that never make the case study.