How we scope a project in a single week.

We used to write proposals. Long ones. Twelve pages of scope definitions, assumptions, risk matrices, and Gantt charts that nobody read past page three. The client would skim the total at the bottom, ask for a discount, and sign. Then the project would start and within two weeks the scope would look nothing like what we'd written, because the act of building revealed things that the act of proposing could not.

So we stopped. In early 2024 we replaced the entire proposal process with a paid five-day discovery sprint. The client pays for the week. We deliver four concrete artifacts. At the end, they have everything they need to decide whether to build with us, build with someone else, or not build at all. And we have everything we need to actually estimate the work — because we've done a piece of it.

§ 01Why proposals don't work

The fundamental problem with a traditional proposal is that it asks you to estimate something you haven't started. You're guessing at the shape of work that hasn't been done yet, based on a conversation that lasted an hour, about a product you haven't touched. The estimate is fiction. Everyone involved knows it's fiction. But the industry keeps pretending otherwise because the format is familiar.

The downstream cost of that fiction is real. The client budgets based on a number that was a guess. The team plans sprints based on scope that was an assumption. When reality diverges — and it always diverges — someone has to absorb the gap. Usually it's the quality of the work, sometimes it's the relationship, occasionally it's both.

A proposal is a guess dressed up as a plan. A discovery sprint is a plan dressed down to what you actually know.

We wanted to replace guessing with knowing. The only way to know what a project involves is to do a small piece of it. That's what the discovery sprint is.

§ 02The five-day discovery sprint

The sprint runs Monday through Friday. It's not five full days of our time — it's five calendar days with focused work blocks. Here's how the week breaks down:

Monday: Intake and audit. We get access to everything — the existing codebase, the analytics, the design files, the deployment pipeline. We read before we talk. By end of day, we've mapped the current state: what exists, what's broken, what's load-bearing, what's dead weight.

Tuesday: Stakeholder interviews. Two to three 45-minute calls with the people who know the product best. Not just the founder — the support lead, the engineer who's been patching things, the person who talks to users daily. We ask the same five questions every time, and the answers are always different from what the founder predicted.

Wednesday: Architecture spike. We build something small and real. A proof of concept for the hardest technical question in the project. If the project is a migration, we move one route. If it's a new feature, we build a working skeleton. The point isn't to ship it — the point is to discover what we don't know yet while there's still time to adjust the plan.

Thursday: Scope definition and estimation. Armed with actual data from the spike, we break the project into two-week sprint blocks. Each block has a clear deliverable, a clear input, and a list of assumptions that would change the estimate if they turned out to be wrong. No Gantt charts. No padding. Just an honest breakdown of what we know, what we're assuming, and what we'd need to learn.

Friday: Delivery and review. We present the four artifacts (more on these below) in a 90-minute session. The client walks away with a complete picture of the project — not a sales pitch, but a technical plan they can take to any team, including one that isn't us.

§ 03The four artifacts

Every discovery sprint produces exactly four things:

1. The audit document. A one-page summary of the current system — what's there, what's working, what's not, what's risky. Written in plain language, not technical jargon. The founder should be able to hand it to their board.
2. The architecture decision record (ADR). A document that explains every major technical decision we'd make, the alternatives we considered, and why we chose what we chose. If the client takes this to another team, that team should be able to follow it without talking to us.
3. The sprint plan. A sequence of two-week blocks, each with a deliverable, a cost, and a list of assumptions. The client can buy one block at a time. There is no commitment beyond the current sprint.
4. The working spike. A deployed proof of concept that demonstrates the hardest part of the project. It's not production-ready, but it runs. The client can see it, click it, and share it. It makes the rest of the plan tangible.

[ FIG. 002 ] — Discovery sprint output deck structure

§ 04What we refuse to estimate

There are things we will not put a number on, and we're upfront about it:

• Third-party API behavior. If the project depends on an external API that we haven't integrated with, we won't estimate the integration time. We'll estimate the spike to learn it, and then estimate the integration after.
• Scope that hasn't been designed. "We'll figure out the admin panel later" means the admin panel doesn't get an estimate. It gets a placeholder that says "TBD after design sprint."
• Performance targets without baselines. "Make it faster" isn't a scope item. "Reduce LCP from 4.2s to under 2.5s" is. If the client doesn't have baselines, the first sprint includes measuring them.
• Anything that requires user research we haven't done. If the feature depends on understanding user behavior we haven't measured, the estimate is for the research, not the feature.

This sometimes frustrates clients who want a single number for the whole project. We understand the desire. But a single number for a six-month project is a lie, and we'd rather be uncomfortable for fifteen minutes in the Friday review than be wrong for six months during the build.

§ 05What the client does during the week

The discovery sprint is not something we do in a room by ourselves. The client is actively involved. On Monday they grant access and answer questions. On Tuesday they join interviews or help us schedule them. On Wednesday they're available for quick questions as we spike. On Thursday they review assumptions. On Friday they receive and challenge the plan.

We ask for two to four hours of the founder's time across the week. That's it. If they can't spare that, we reschedule. The sprint only works if the people with context are reachable.

§ 06After the sprint

About 80% of discovery sprints convert to engagements. The other 20% don't, and that's fine. Sometimes the sprint reveals that the project is smaller than the client thought, and they can handle it internally. Sometimes it reveals that the project is bigger, and they need to raise more capital first. Sometimes they take our plan to a cheaper team. All of these are good outcomes — the client made an informed decision instead of signing a contract based on a guess.

For the projects that do move forward, the sprint has already de-risked the first two weeks. The architecture is decided. The spike is done. The first sprint block starts on Monday with the team already in motion, not spending the first week figuring out what to build.

We charge for the discovery sprint because it's real work that produces real value. It's also the best sales tool we've ever had, because by Friday the client has seen how we think, how we build, and how we communicate. The proposal is the work. The work is the proposal.

— End of essay. Want to run a discovery sprint for your project? Start a project →