When someone internally champions a software project, the instinct of the person signing the budget is usually the same: skip the preamble, get a quote, make a decision. It feels efficient. It feels like protecting the organisation’s time. The problem is, it’s actually the riskiest thing you can do — and the industry has a graveyard full of projects that prove it.
The software discovery phase is one of the most misunderstood parts of building anything digital. It sounds like a warm-up. A consultancy nicety. Something agencies insist on to pad their invoices before the real work begins. In reality, it’s the opposite: it’s the mechanism that protects the buyer — not the agency — from the most expensive mistake in software development, which is building the wrong thing.
A proposal without discovery is a guess
When an agency skips discovery and hands you a fixed quote based on a brief conversation and a vague spec, they’re not being efficient. They’re being optimistic. They don’t yet know what you actually need, so they’re pricing what they think you need, with enough contingency baked in to cover the gap between the two. That’s not a quote. It’s a guess dressed up in a PDF with your logo on it.
The discovery phase changes that. It’s a structured process — typically a few weeks — in which a development team digs into your operations, your existing systems, your workflows, your constraints, and your actual goals. Not the goals in the brief. The real ones. The output isn’t a recommendation to build anything. It’s a specification: a document that defines exactly what needs to be built, why, and how. Something you own entirely, regardless of who builds it.
What getting it wrong actually costs
IBM’s research has consistently found that fixing a software error in production costs up to 100 times more than catching it during the requirements phase. The Standish Group’s Chaos Report, which has tracked software project outcomes for three decades, regularly finds that roughly a third of all software projects fail outright, and a significant proportion of the rest deliver over budget, late, or with fewer features than planned. The leading cause, consistently, is poorly defined requirements at the start.
A client came to us after experiencing exactly this. They’d commissioned a development team to build a platform, handed over a functional spec, and the team had simply started building. No discovery. No challenge to the brief. No investigation of whether the spec actually reflected what the business needed. Eighteen months later, the project had never finished, and a significant portion of what had been built turned out to be irrelevant to how the organisation actually operated. Total spend: $150,000. When we ran a proper discovery process, we found the project was premature — the underlying operational foundations weren’t in place to support the platform they’d been trying to build. Done correctly, from the right starting point, the same outcome could have been achieved for £85,000. The money wasn’t just wasted on bad code. It was wasted on the wrong answer to the wrong question.
What a vague proposal should tell you
If an agency can give you a detailed, fixed quote within a week of your first conversation, ask yourself how they arrived at that number. Either they’ve built something so similar before that they genuinely don’t need to investigate — which is possible but rare — or they’re estimating. And when estimates go wrong on a software project, it’s never the agency absorbing the overrun. It’s you.
The agencies that insist on discovery before quoting are not being difficult. They’re being honest. They’re telling you that they take requirements seriously enough to charge for getting them right. That discipline — the willingness to slow down before building — is usually a reliable indicator of how the actual build will be managed.
Yes, discovery costs money. That’s the point.
A discovery engagement typically costs a few thousand pounds. It produces something tangible: a specification document you own outright. You could take that document to three different developers and get three comparable quotes. You could shelve it for six months and return to it when the timing is right. You could use it internally to build a business case. None of that is possible with a vague proposal from an agency that hasn’t asked the right questions yet.
The discovery phase isn’t a commitment to build anything. It’s a commitment to understanding what you’d be building before you spend money building it.
The question isn’t whether discovery is worth the investment. The question is whether you can afford to skip it — and that’s a question the $150,000 project above has already answered.
Interested in understanding how a structured discovery process works in practice? Learn more about our Strategy & Discovery service.