Pricing a discovery sprint honestly

Almost every software project worth doing starts with uncertainty. You know the problem, roughly, but not the best solution, how long it will take, or whether the data and systems you depend on will cooperate. A discovery sprint is a short, focused piece of work to reduce that uncertainty before anyone commits to a full build.

It is also one of the most awkwardly priced things in the industry. Some suppliers give discovery away to win the build, then recover the cost somewhere less visible. Others run it on an open-ended daily rate that quietly grows into a project of its own. Neither is good for the client, and neither is honest about what discovery is for.

Here is how we think a discovery sprint should be priced, whether you are buying one or selling one.

01#Fix the time, fix the price

The defining feature of discovery is that you don't know in advance what you will find. That makes it tempting to leave the scope open. It is better to do the opposite: fix the duration and the price, and let the findings be the thing that varies.

A fixed window, often one to three weeks for a focused problem, forces prioritisation. The team has to decide early which questions matter most and answer those first. An open-ended discovery tends to explore everything with equal care and finish nothing.

A fixed price means the client knows exactly what they are committing to before they start. There is no surprise invoice when the investigation turns out to be harder than expected. If the supplier underestimated, that is their problem to absorb and learn from, which is the right incentive.

02#Name the outputs in writing

"Discovery" can mean anything from a few workshops to a working prototype. Before the sprint starts, write down what the client will hold at the end. A useful set is:

• →A clear problem statement. What is being solved, for whom, and how you will know it worked.
• →A plan for the build. What would be built first, in what order, and what is deliberately left out.
• →Evidence for the hard parts. If the risk is a messy data source or an unproven integration, a small working test that shows it can be done, or that it can't.
• →A fixed quote for the next stage. Or, if that isn't yet possible, a precise statement of what would need to be true to give one.
• →A list of risks and open questions, each with a suggested way to close it.

Writing these down does two things. It gives both sides a shared definition of done. And it makes the sprint's value visible even if the project doesn't go ahead, because the client walks away with documents and evidence they own.

03#Say upfront what you might find

This is the part most often skipped. A discovery sprint can end in three ways:

• →Build it, as planned. The idea holds up and the plan is clear.
• →Build something different. The real problem is not the one you started with, or a smaller, cheaper version solves most of it.
• →Don't build it. The data isn't there, the cost outweighs the benefit, or an existing tool already does the job.

All three are legitimate results. The third is often the most valuable, because it saves the cost of a full build that would have disappointed. But it only feels like a success if it was named as a possible outcome before the sprint began. Otherwise it feels like failure, and suppliers are tempted to steer away from it.

So say it plainly at the start: "One possible answer is that you shouldn't build this. If that is what we find, we will tell you, and the plan and evidence are still yours."

04#Should discovery be free?

It is common for suppliers to offer free discovery, and it is easy to see the appeal for the client. But free work has to be paid for somewhere, usually in a higher build price, and it creates a strong incentive to conclude that the build should go ahead. A supplier who isn't paid for discovery isn't really free to tell you not to build.

A paid, fixed-price sprint keeps the incentives straight. One fair approach, and the one we use for our own sprint, is to charge for the sprint and credit its fee against the build if the client goes ahead. The client pays for the thinking either way. If they proceed, they don't pay for it twice. If they don't, they have paid a known amount for a clear answer.

05#Questions to ask when buying one

If you are being offered a discovery sprint, these questions will tell you a lot:

• →How long is it, and what is the total price? Is either open-ended?
• →What exactly will we have at the end? Can we see an example?
• →Who will do the work, and how much of their time will it get?
• →What happens if you find that we shouldn't build this?
• →If we go ahead, is the sprint credited against the build?
• →Will we own everything produced, including any prototype code?

A supplier who answers these clearly, in writing, is likely to run the rest of the project the same way.

06#The real product is a decision

A discovery sprint isn't really about workshops, documents or prototypes. Its product is a well-informed decision: build this, build something else, or stop. Pricing it honestly means charging a fixed amount for a fixed period, being specific about what you will deliver, and being genuinely open to every answer.

Done that way, discovery stops being a sales tactic and becomes what it should be: the cheapest point in a project to change your mind.