Sprint Types
Three modes, one methodology. Every engagement ends with evidence.
Sprint Types
Three modes, one methodology. Every engagement ends with evidence.
Build Sprint
One critical flow. Validated and shipped to your codebase.
You pick the flow that matters most. It's designed, built in your codebase, and tested with real users.
| Day | What happens |
|---|---|
| Day 1 | Workshop — align on the one flow, lock scope |
| Days 2-4 | Build — working flow shipped to your codebase |
| Async gap | Your users test it on their timeline |
| Day 5 | Results — expert analysis, UX fixes, presentation |
You get: Working code in your repo. User testing data. Evidence-based iteration. A validated flow, not a Figma file.
Validate Sprint
Your product. Tested with real users.
For products that exist but haven't been tested. We design a rigorous testing protocol, run 5-6 live sessions with real users, and deliver evidence-backed recommendations.
| Day | What happens |
|---|---|
| Day 1 | Workshop — define what to test and why |
| Day 2 | Prepare testing protocol, confirm participants |
| Days 3-4 | 5-6 facilitated user testing sessions |
| Day 5 | Analysis, quick UX fixes, strategic presentation |
You get: Recorded sessions. ICP-weighted analysis. Quick fixes shipped. A prioritised roadmap based on what users actually did, not what anyone assumed.
Works standalone for existing products, or as the natural follow-up to Build Sprints.
Visual Sprint
Design system and visual polish — inside multi-sprint engagements only.
When the product works but needs visual coherence. Brand implementation, component polish, typography, spacing, design system creation. Available only as part of a larger engagement, always followed by a Validate Sprint.
| Day | What happens |
|---|---|
| Day 1 | Visual direction briefing — brand, references, quality gaps |
| Days 2-4 | Component polish, design system, brand integration |
| Day 5 | Before/after presentation, design system handoff |
| Next sprint | Validate Sprint — tests whether visual changes improved user perception |
You get: Polished product at Series B/C visual standard. A documented design system your team can build on. And because it's always followed by validation — evidence that the changes actually work for users.
Engagement Examples
Clients don't pick sprint types from a menu. We propose the right journey for what they need.
| Need | Journey | Sprints |
|---|---|---|
| Ship one critical flow | Build | 1 |
| Ship and validate | Build → Validate | 2 |
| Overhaul an existing product | Validate → Build → Validate | 3 |
| Full transformation | Build → Build → Validate | 3 |
| Build, polish, prove | Build → Visual → Validate | 3 |
| Comprehensive | Build → Visual → Build → Validate | 4 |
| Test what you already have | Validate | 1 |
When the product already exists and needs overhauling, we always start with Validate. Testing the current product first means every design decision in the Build sprint is grounded in real user evidence — not assumptions about what's broken.
Every engagement ends with a Validate sprint or validated Build sprint. The endpoint is always evidence, not opinion.