£400,000. That's what a 400-person professional services firm nearly spent on a full website and CRM rebuild. The COO had a nagging feeling something wasn't right about the brief, so they asked us to take a look before signing anything. Two weeks later, we told them that roughly 60% of the original scope was unnecessary. The actual problem - a broken enquiry-to-onboarding handoff - got fixed in a 90-day sprint for about £80k. They avoided £320k of wasted spend and saw a 22% improvement in enquiry-to-client conversion within three months.
That assessment? That was discovery. And the firm nearly skipped it.
I tell that story not because it's unusual, but because it's typical. In over two decades of delivering digital projects, the pattern is so consistent it barely qualifies as a pattern anymore - it's more like gravity. Projects that skip discovery cost more, take longer, and deliver less. Projects that invest in understanding the problem before committing to a solution tend to land. Not always perfectly, but reliably closer to the mark.
And yet, discovery remains the phase that gets cut first. Every time.
Let's get this out of the way. I know what discovery sounds like from the client side. It sounds like the agency equivalent of a mechanic sucking air through their teeth before telling you it's going to be expensive. Pay us to think about your problem for a bit, then we'll tell you what you need to buy from us. Start the meter running.
I get it. I genuinely do. If I'd been burned by a previous agency that charged £30k for a discovery phase and handed me a 60-page PDF full of things I already knew, I'd be cynical too. And honestly, some discovery processes deserve that cynicism. I've reviewed the outputs from other firms' discovery phases that were little more than back-of-the-envelope requirements gathering dressed up in a fancy template. That's not discovery. That's admin with a markup.
But the fact that some firms do discovery badly doesn't mean discovery itself is unnecessary. That's like saying you'll never see a doctor again because the last one misdiagnosed you. The answer isn't to skip the diagnosis - it's to find someone who actually knows what they're looking at.
We already know what we need. We don't want to pay for someone to tell us what we already know.
Sometimes that's true. I'll be honest about that. Some organisations have genuinely done the internal work - mapped their user journeys, interviewed their customers, audited their technology stack, and arrived at a clear, prioritised brief. If that's you - really you, not "we had a brainstorm in the boardroom and the senior partner's opinions won" you - then a full discovery phase might not be what you need. Maybe a shorter validation exercise. Maybe a technical assessment to pressure-test your assumptions. But you'd be surprised how rarely that's actually the case.
More often, what I see is a firm that knows it has a problem but has self-diagnosed the solution. "We need a new website" when the real issue is that the CRM doesn't talk to the CMS and leads are falling through the cracks. "We need to replatform" when the actual bottleneck is that the content team can't publish without filing a developer ticket. The solution they've landed on isn't wrong, exactly - it's just expensive and incomplete, because nobody asked the right questions first.
Discovery is a structured investigation. That's it. You're paying for someone to understand the problem properly before committing to a solution.
Stakeholder interviews - and not just with the person who commissioned the project. The marketing director thinks the problem is the website. The IT lead thinks the problem is the CMS. The finance director thinks the whole thing costs too much. The fee earners think nobody's asked them what they need. Discovery surfaces those different perspectives early, when they're useful, rather than halfway through a build, when they're destructive.
User research - talking to the people who actually use the thing you're about to change. I remember a project a few years back where the client was convinced their portal needed a visual redesign. We spent three days watching users try to complete basic tasks on the existing platform. The design wasn't the problem. The information architecture was so convoluted that users couldn't find anything - they'd click four levels deep, hit a dead end, and just give up. A redesign would have made a broken thing prettier. Not the same as making it work.
Technical assessment - understanding what you're actually working with. I've seen teams six weeks into a build discover that the legacy system they assumed could be retired is actually the only thing connecting the CRM to the finance platform. Usually because the person who built it left three years ago and nobody fully understood it since. That kind of surprise is avoidable. It's avoidable with discovery.
And then prioritised recommendations. Not a wish list. Not "here are 47 things you could do." A clear, honest assessment of what matters most, what can wait, and what you probably don't need at all.
You solve the wrong problem. A mid-sized consulting firm came to us after spending the better part of a year rebuilding their website. Beautiful thing. Really well designed. And it made almost no difference to their pipeline, because the problem was never the website itself - it was that the firm had 40+ published articles, frameworks, and research papers that were completely invisible online. The content existed. The platform to surface it didn't. They'd spent their budget on aesthetics when the issue was architecture and content strategy. A proper discovery phase would have caught that in week one.
Scope explodes. Without discovery, scope is defined by assumption. And assumptions are generous things - they tend to multiply. "While we're at it, can we also..." is the sentence that has killed more project budgets than any technical failure. Discovery creates a boundary. It gives you a defensible reason to say "that's phase two" because you've done the work to understand what phase one actually needs to achieve.
Stakeholders collide mid-build. I've been in rooms where the marketing team and the IT team are having completely different conversations about the same project. Marketing wants editorial independence and brand flexibility. IT wants platform consolidation and security compliance. Both are legitimate. But if nobody surfaces those tensions before the build starts, you end up with a platform that half-satisfies both and fully satisfies neither. Discovery is where you have those arguments productively - before there's code to unpick.
Rework becomes the norm. A team builds something based on incomplete understanding, shows it to stakeholders, gets feedback that fundamentally changes the direction, rebuilds, gets more feedback, rebuilds again. Each cycle costs time and money, obviously - but it also costs morale. The delivery team gets demoralised. The client loses confidence. And the relationship starts to curdle.
So you've committed to doing discovery. How do you know whether what you got back was worth the investment?
The first question is whether you understand the problem better than you did before. Sounds obvious, but it's the most important one. If the discovery outputs just confirm everything you already believed, either you were completely right from the start (possible but unlikely) or the discovery wasn't rigorous enough. Good discovery should challenge at least one of your assumptions. If it doesn't surprise you even once, something's off.
The second is whether the recommendations are prioritised, not just listed. Anyone can produce a list of things that need fixing. The value is in the sequencing - what do you do first, what depends on what, what can you defer without increasing risk. If you're handed a flat list with no prioritisation, you haven't received a strategy. You've received a to-do list.
And the third - did the team ask uncomfortable questions? Good discovery involves asking things like "why did the last project fail?" and "what does the leadership team actually disagree about?" and "where are you losing customers and why?" If nobody asked anything that made you slightly uncomfortable, they were probably being polite rather than thorough.
Discovery isn't something that happens to you. The quality of what comes out is directly related to how much you put in.
Be available. Not just the project sponsor - the people who actually do the work, manage the clients, use the systems, handle the complaints. Every stakeholder interview that gets cancelled or delegated to someone junior is a gap in understanding that will show up later.
Be honest about constraints. Budget, timeline, internal politics, that legacy system nobody wants to touch. The more the discovery team knows about the real landscape - not the polished version - the better the recommendations will be.
And be willing to hear things you don't want to hear. Sometimes discovery reveals that the project you had in mind isn't the project you need. That the budget you've allocated isn't sufficient for what you're trying to achieve. That the timeline is unrealistic. Those are uncomfortable conversations. They're also the conversations that save you from a much more uncomfortable one twelve months later when the project has gone sideways.
Look - sometimes discovery confirms that what you thought you needed is exactly what you need. That happens too. And when it does, you haven't wasted the investment. You've bought confidence. You've bought alignment. You've bought a shared understanding across your leadership team about what you're doing and why. That's worth something, especially when you're six months into a build and someone asks "remind me why we're doing this?"
I think the reason discovery gets cut is that it sits in an awkward psychological position. It's the thing you do before the thing you actually want to do. It feels like a delay. It feels like overhead. And when budgets are tight - which they always are - it's the easiest line to remove because the consequences aren't immediate. They're deferred. They show up three months later as scope changes. Six months later as budget overruns. Twelve months later as a platform that doesn't do what anyone expected.
I was in a conversation recently with an operations director at a professional services firm who told me, with total sincerity, that they'd saved £40k by skipping the discovery phase on their last digital project. The project came in £180k over budget and took five months longer than planned. I didn't have the heart to do the maths for him out loud. But the maths does itself, doesn't it?
The most expensive digital projects I've ever seen aren't the ones with ambitious scope or complex integrations. They're the ones that started building before anyone properly understood what they were building, or why.
If you're considering a digital project - a replatform, a redesign, a new portal, an AI initiative, whatever it is - and you're weighing up whether discovery is worth the investment, flip the question. Can you afford the cost of getting it wrong? Because that's what skipping discovery actually puts on the table.