"Discovery sprint" gets used for everything from a two-day workshop to a fully scoped pre-build phase. Ours is the latter — twelve weeks, three engineers and a designer, before we write anything meant for production. Clients ask what that time actually buys them, so here's the literal breakdown from a recent engagement.
Weeks 1–2: Problem definition, not solution definition
We spend the first two weeks explicitly not talking about features. Stakeholder interviews, support ticket analysis, and — where it exists — a look at usage data from whatever the client is replacing or extending. The deliverable is a single document every stakeholder signs off on: the problem statement, who it affects, and what "solved" looks like in measurable terms. Skipping this step is the single biggest cause of scope drift we see in projects we're brought in to rescue.
Weeks 3–5: Technical spikes on the genuinely risky parts
Not every part of a system carries equal risk. We identify the two or three technical unknowns that could sink the timeline — a third-party integration with thin docs, a data model that has to support two conflicting access patterns, a real-time requirement with no obvious off-the-shelf answer — and we build throwaway code to de-risk exactly those, before committing to an architecture.
// Answer, after 3 days of testing: no. Architecture has to
// assume out-of-order delivery and reconcile by event timestamp,
// not arrival order. This changes the data model.
async function reconcile(events: WebhookEvent[]) {
return events
.sort((a, b) => a.occurredAt - b.occurredAt)
.reduce(applyEvent, initialState);
}That single spike changed the core data model. Finding it in week 4 cost three days. Finding it in month three of the build would have cost a rewrite.
Weeks 6–8: Architecture and design in parallel, not sequence
Design without engineering constraints produces beautiful mockups that get quietly redesigned during implementation. Engineering without design input produces technically sound systems nobody wants to use. We run these two tracks in parallel with a standing sync twice a week specifically to catch the moments where a design decision has an architecture cost, or vice versa, while it's still cheap to change.
Weeks 9–10: A clickable, load-bearing prototype
Not a Figma flow — a real prototype against real (or realistic seeded) data, enough to run it in front of five to eight actual target users. This is where we catch the gap between what stakeholders think users want and what users do when they're handed the thing.
Weeks 11–12: The build plan a team can actually estimate against
The output isn't a deck. It's a scoped, sequenced backlog with architecture decisions already made and documented, ready to hand to a build team — ours or otherwise — with confidence in the estimate, because the risky unknowns were resolved in weeks 3–5, not discovered in week 20 of the build.
What this replaces
Most of our discovery-sprint clients came to us after a first attempt that skipped straight from a pitch deck to a build team, and hit an expensive surprise around month three. Twelve weeks feels slow in a kickoff call. It's consistently faster than the alternative.