What a Discovery Sprint Actually Is and What You Get From One
Two weeks of technical investigation before any code is written. Here is exactly what happens and what you receive at the end.
A discovery sprint is two weeks of technical investigation before any code is written. Week one maps what exists, identifies user journey gaps, and lists every assumption with its validation status. Week two documents architecture options and produces a prioritised roadmap with estimates. You get five deliverables at the end and no obligation to build anything.
The most expensive mistake in product development is building the wrong thing correctly. A discovery sprint is the mechanism we use to avoid that. Two weeks. A technical team that reads your codebase or your specification, maps the architecture, identifies the gaps, and produces a roadmap before a single line of new code is written.
This document explains exactly what happens during a discovery sprint, what we are looking for, and what you receive at the end.
Week One: Understanding What You Have
Day 1-2: Codebase or specification audit. If you have an existing product, we read the code. Not to judge it but to understand it. We are mapping what exists, how the different parts connect, and where the fragile points are. If you are pre-build, we read your specification and documentation and do the same thing to the plan.
Get posts like this when they go up no noise, just relevant.
Day 3-4: User journey mapping. We map every path a user takes through the product. We are looking for the gaps between what the code or spec says will happen and what users will actually try to do. This is where most of the hidden problems live.
Day 5: Assumption identification. Every product is built on assumptions. Some of them are correct. Some of them are not. Building on a wrong assumption is how you spend six months building something that cannot be used. We list every assumption we find and flag which ones have been validated and which ones have not.
Week Two: Building the Roadmap
Day 6-8: Architecture options. For every significant problem identified in week one, we document the options for addressing it. Not just the recommended option but all viable options, with the tradeoffs between them explained in plain language. You make the decisions. We give you the information to make them.
Day 9-10: Technical roadmap. A prioritised list of the work required to reach your next milestone, with estimates and dependencies. By the end of week two, you know exactly what needs to be built, in what order, and approximately how long it will take.
What You Receive at the End
- Architecture map: a diagram of what exists and how the components connect
- Assumption log: every assumption found, with validation status
- Risk register: the fragile points ranked by severity and likelihood of causing problems
- Technical roadmap: prioritised work with estimates and dependencies
- Build vs buy recommendations: for each major component, a clear recommendation
What a Discovery Sprint Is Not
It is not a commitment to build anything. The deliverable is information and a roadmap, not code. At the end of two weeks you are in a better position to make the build decision, with us or with anyone else.
It is not an evaluation of your decisions. We are not there to tell you that the product idea is wrong or that your original developer made mistakes. We are there to tell you what exists, what it means for what you want to do next, and what the options are.
If you are trying to decide whether a discovery sprint is the right next step, hamza@forgex.systems. Tell me where you are and I will tell you honestly whether it would help.
Frequently Asked Questions
What exactly is a discovery sprint and how long does it take?
A discovery sprint is two weeks of technical investigation before any new code is written. A technical team reads your existing codebase or specification, maps the architecture, identifies gaps and unvalidated assumptions, and produces a prioritised roadmap. The output is information and a plan, not code.
What happens during the first week of a discovery sprint?
Days one and two are a codebase or specification audit to map what exists and where the fragile points are. Days three and four are user journey mapping to find gaps between what the code says will happen and what users will actually try to do. Day five is assumption identification, where every assumption in the product is listed and flagged as validated or not.
What happens during the second week of a discovery sprint?
Days six to eight document the architecture options for every significant problem found in week one, with tradeoffs explained in plain language so the founder can make informed decisions. Days nine and ten produce the technical roadmap, a prioritised list of work required to reach the next milestone with estimates and dependencies.
What do I actually receive at the end of a discovery sprint?
You receive five documents: an architecture map showing how all components connect, an assumption log with validation status for each assumption, a risk register ranking fragile points by severity and likelihood, a technical roadmap with prioritised work and estimates, and build versus buy recommendations for each major component.
Does a discovery sprint mean I am committing to build with that team?
No. The deliverable is information and a roadmap, not code and not a commitment. At the end of two weeks you are in a better position to make the build decision, with the same team or with anyone else. The sprint is designed to give you clarity, not to lock you in.
Why should I do a discovery sprint before building my product?
The most expensive mistake in product development is building the wrong thing correctly. A discovery sprint surfaces unvalidated assumptions, hidden gaps in the user journey, and architectural risks before any money is spent on building. Building on a wrong assumption is how a team spends six months creating something that cannot be used.
Is a discovery sprint only for products that already have code, or can I do one before I build anything?
Both. If you have an existing product the team reads the codebase. If you are pre-build the team reads your specification and documentation and applies the same process to the plan. The output in both cases is the same: an architecture map, an assumption log, a risk register, and a technical roadmap.
Work with Forgex
If this sounds like where you are, I'd like to hear what you're building.
hamza@forgex.systems
