Paid Discovery: What It Is and Why Not to Skip It

You ask someone to build software. They ask you to pay for Discovery before they'll give you a quote. It's a fair thing to question. You're already considering paying for the build. Why should figuring out the price become another piece of paid work? A good builder should know what they're doing, and winning your business is their job.

I agree that you shouldn't pay for someone's sales pitch. You should be able to talk, ask questions and decide whether you want to work together. Where I disagree is the idea that understanding how your business runs belongs inside that sales conversation. A paid discovery phase pays for that understanding and the decisions that follow. I treat it as part of doing the work properly.

Why I won't price an unknown process

My view is that a quote without discovery either has room added for risk or leaves necessary work unpriced. You pay for the uncertainty in the quote, in later changes or in work that never gets done. Putting a fixed number on an unknown process doesn't make the unknowns disappear.

Take a request like "we need an order system." Does that mean recording an order, or also reserving stock, booking a courier and handling a damaged item? Who can change an order after the warehouse starts packing? What happens when a part is missing? Until those questions have answers, you and the builder can agree on the words while imagining different work. The decisions made before the build set most of what the build will cost. The number of screens tells you little without the rules behind them.

I treat free discovery as a sales conversation. It can establish whether we're a fit and whether the problem is something I can help with. It doesn't replace following a real order with the people handling it. Without that work, I'd be pricing my assumptions about your company. I'd rather put those assumptions in front of you before they become features, exclusions or extra work. I explain the practical cost decisions in what drives custom software cost.

There's a wider project lesson here. In PMI's 2014 study of requirements management, when projects missed their original goals, inaccurate requirements management was the primary cause almost half of the time (47%). That research concerns requirements: deciding what the work must deliver and keeping those decisions clear. It gives me a reason to take that work seriously before a build starts.

For software estimates specifically, Steve McConnell's Cone of Uncertainty shows early estimates ranging from a quarter to four times the final effort. In his words, the cone "narrows only as you make decisions that eliminate variability." Asking a builder to think harder about a number doesn't answer who approves a return. Someone has to make that decision. I want it made with the people responsible for the work, before I price the work around it.

What my paid Discovery actually involves

My paid Discovery takes 1-2 weeks and ends with a written proposal with a fixed scope and price. I look at how your business runs with you, your leaders and the people doing the work. We work out what to simplify, change or build before agreeing on a build.

The starting point is the business problem. Work is spread across paper, spreadsheets and chat. People copy details between tools. Every exception lands with you. I want to understand how those things connect before deciding what needs to change. A new app won't decide who is responsible for keeping an order accurate. Sometimes the answer is to change a process, not to build anything. That is a useful result from Discovery, even when there is no software to show for it.

When the fix needs software, I build custom apps, mini ERPs and automations around how the business works. I use AI coding tools, and I stay involved through rollout, troubleshooting and ongoing improvements. Support and improvements are monthly. You can see how we work together. The point of Discovery is to get clear about the work worth doing before we agree to do it. You still make the business decisions; I help you think them through and carry out the agreed work.

Start with one real order, not a feature list

Bring a real order or job to discovery and follow it with the people who handle it. Show the paperwork, the spreadsheet and the messages that change what happens next. I want to see where information gets copied, where work waits and which decisions still need the owner to step in.

At Silla, I mapped every step from order to complaint with the people doing the work each day. Before the app, an order came from the website, went onto paper and into Excel, then into the courier's system. The address was copied for the third time. Finding an order's status could take up to 15 minutes of searching across apps. Those details explain the work to be done much better than "we need a dashboard." They identify the information that has to move and the copying that can stop.

Silla's app now tracks stock by component and reserves it for open orders. A packing task stays open until the correct model, color and quantity have been scanned. Those are specific rules about how the business works. For your own discovery, bring an ordinary job and one that went wrong. Ask the person who dealt with the exception to explain it. Then ask who should decide what happens next. If two leaders give different answers, settle that before asking a builder to put either answer into software.

What a good discovery should leave you with

Good discovery should leave you able to explain what's changing, what's staying and what you're agreeing to pay for. From any builder, I'd expect a clear account of today's work and the proposed changes. Use this checklist to judge the result, rather than the length of the document or the polish of a presentation.

A map of today's work: The steps from the first request to the finished job, including who handles each step and where the information lives. The people doing the work should recognize it.

Changes without software: The duplicate list you can stop keeping, the responsibility you need to assign or the approval rule you need to settle. Separate those changes from the proposed build.

Scope and exclusions: What the software will do and what it will leave out. "Handles orders" needs enough detail that you and the builder can agree when that work is complete.

A fixed price for that scope: A price attached to the defined work. Ask what happens if you later request something outside it, so you understand how that decision will be handled.

A decision maker on your side: A named person who can settle competing requests and approve business rules. Include the people who need a say, while making clear who makes the final call.

Risks: The unanswered questions that could change the work. Old stock records, access to another system or an unsettled approval rule belong in the discussion before you agree to build around them.

A rollout plan: How people will start using the system, who needs to be involved and how problems will be raised. Ask what happens to the old records when the new way of working begins.

When a quote without paid discovery is enough

A quote without paid discovery is reasonable when the work is already clearly defined. If you've settled the business rules, records, connections and exclusions, give that material to the builder. I wouldn't pay someone to repeat useful work just to satisfy a label. The test is whether they understand the scope well enough to price it.

Find what still comes back to you

If you want a starting point before discussing a build, try the free Business MRI: 10 questions, about 2 minutes, no email needed to see your result. It gives you a founder dependency score showing how much runs on you, your three weakest areas and a first move for each. It's optional and separate from paid Discovery.