A discovery sprint is one fixed week before the build. You and the team agree on what the first release must do, how it will be built and what it will cost. At the end you get a fixed price you can accept, take to another team or walk away from.
Our guide to the discovery phase covers the process day by day and every deliverable. This one answers the question founders ask first: do I need one, or can I skip straight to the build?
A fixed price needs a fixed scope. When a team quotes from a two-paragraph idea, they’re guessing. Either they pad the price to cover what they can’t see, or the price grows once the real work shows up.
Many agencies sell at a fixed price. In the Rocketech MVP Price Index 2026, 20 of the 41 agencies that state their own MVP price sell at a fixed price or in fixed packages, with a median starting price of $8,200. These are published prices, not what agencies charge after scoping. A fixed price is only as good as the scope it was written for.
Developers feel the same gap from the other side. In the Stack Overflow Developer Survey 2026, unclear priorities or requirements was the top reason respondents gave for their job getting harder in the past six months: 16.6% of 18,214 people. A week spent making the scope clear saves both sides from that.
The names sound alike, but they answer different questions.
| Discovery sprint | Design sprint | Discovery phase | Customer development | |
|---|---|---|---|---|
| Main question | What exactly do we build, and for how much? | Will customers want this solution? | What is the whole problem, and should we go on? | Is there real demand? |
| Length | 1 week | 5 days | 1 week to several weeks | Ongoing |
| What you get | Scope, clickable main screens, technical plan, backlog with hours, fixed price | A realistic prototype tested with customers | A decision to build, change or stop, plus the documents behind it | Evidence from interviews, pre-orders and pilots |
| Who leads | The team that will build it, with you | A product team | The product team | The founders |
The design sprint from GV spends Friday interviewing customers and watching them react to a prototype. A discovery sprint doesn’t include user testing. It turns what you already know into a plan and a price. That’s why the two work well together. Neither one replaces ongoing customer development.
When this post first ran, we listed why founders resist discovery. The reasons haven’t changed, so here are the answers.
A free estimate is useful, and we give one. But a scope, a technical plan and a backlog with hours take days of work from the people who’ll build the product. When that work is free, its cost tends to come back in the build price.
Requirements change once building starts. A 50-page spec written before anyone has tried the hard part gets thrown away. A short written scope of a few pages, plus a test of the riskiest part, holds up better.
It shares it. You bring what you know about users and the business; the team brings the hours and the technical risks. Both sides sign off on the same scope.
It needs four to five hours of your time: a 2-3 hour kickoff on day 1, two 30-minute reviews on days 2 and 4, and a 1-hour readout on day 5. The team does the rest.
Our discovery sprint is a fixed $3,000 for 1 week. If you then build the MVP with us, the $3,000 counts toward it in full. If you don’t, the files are yours, and any team can use the scope and backlog as a brief.
You get a written scope, the main screens in a clickable prototype, a technical plan, a day on the riskiest technical question where there is one, a backlog with hours and a fixed price for the build. It doesn’t include testing with users, market research, designs for every screen, production code, a brand or an investor deck. The discovery phase guide walks through each deliverable.
Discovery can also be smaller than a week. For Daisy’s Guide, a parenting guidebook turned into a web app, a paid discovery of about 10 hours came first. It ended with a plan and a priced scope. Then a small team built the app in two-week sprints, and it reached a beta with real couples about 2 months after kickoff.
Start with a range, then buy the fixed price only if the range makes sense.
Our project estimate turns your brief into user stories. You confirm what’s in scope, and every hour in the budget traces back to a story you kept. We check the hours the model suggests against what our team actually books on finished projects, then multiply by our published rate of $39-55 an hour. It’s a planning range, not a fixed quote. The discovery sprint is where the range becomes one price.
For market size, the estimate suggests customer groups and gives each one a TAM, SAM and SOM with a note on what the number covers. Treat them as hypotheses to test, not verified demand, because market research isn’t part of the sprint. Get a free project estimate before you book anything.
A fixed, one-week block of work before the build. The founder and the team agree on the scope, draw the main screens, write a technical plan, test the riskiest part and produce a backlog with hours and a fixed price for the build.
Ours is a fixed $3,000 for 1 week. If you build the MVP with us, the $3,000 counts toward the build in full. If you don’t, the scope and backlog are yours to take to any team.
A discovery sprint plans the build: scope, technical plan, backlog and price. A design sprint, as GV describes it, ends with customers testing a prototype. One answers “what will it cost?”, the other “will customers want it?”
Not always. Skip it if the scope is small, written down and low-risk. Book one if you want a fixed price, have nothing written yet or have one technical question that could sink the product.
No. It plans the build and tests the riskiest technical part. To test demand, run problem interviews before the sprint and solution interviews with the prototype after it.
A discovery sprint should connect customer evidence to a build or no-build decision. Review startup development and the Guestroom project reference to distinguish product-delivery questions from the demand assumptions you still need to test. Explore software development for startups and the Guestroom case study.
Discuss buyer evidence and a bounded discovery sprint
Start with an AI-assisted project brief covering scope, budget, market assumptions and risks. Review its hypotheses before making a commitment.
Carefully curated content for resourceful Devs, CTOs, and PMs. No spam.