The phase everyone wants to skip
Discovery is the part of a website project clients most want to cut, and the part they most regret cutting. It sits before any visible progress, so it feels like paying to talk about a website instead of building one. We understand the instinct. We also know how the story ends when discovery gets skipped, because we are the ones who get called in to fix it.
Discovery is structured, up-front work that exists to de-risk the build. It is where we replace assumptions with decisions, turn a vague brief into a concrete plan, and find the expensive problems while they are still cheap to solve. A good discovery phase does not slow a project down. It stops the project from stalling three-quarters of the way through, when a surprise nobody planned for forces a rethink of work that is already half built.
The point of this article is to be specific about what "doing discovery properly" actually means. Not the abstract virtue of planning, but the concrete things a discovery phase should hand over, and why each one saves money later.
What discovery actually is
Discovery is the deliberate work of understanding the problem before committing to a solution. For a website, that means getting clear on what the business needs the site to do, who it serves, what content it holds, how it is structured, what it must be built on, and what could go wrong.
It is not a kickoff meeting. A kickoff is an hour of enthusiasm and a shared calendar invite. Discovery is a focused block of work with named outputs, usually a small fraction of the total project effort, that produces documents and decisions the whole build then leans on.
The mindset shift we ask clients to make is this: the build is where you spend the money, so discovery is where you make sure the money is spent on the right thing. Every hour spent deciding what to build is an hour that protects the far larger spend on building it.
What a good discovery hands over
A discovery phase should produce artefacts, not just conversations. When we finish one, the client can hold the outputs in their hands and a different agency could pick up the build from them cold. That is the test. Here is what should be in that package.
- Clear goals and success metrics. What is this site actually for, and how will we know it worked? "More leads" becomes a target, a baseline, and a way to measure it. Without this, nobody can say whether the finished site is a success or an expensive redesign.
- Audience and user understanding. Who uses the site, what they are trying to do, and where the current experience fails them. This is the difference between a site that looks good and a site that converts.
- A sitemap and information architecture. The full map of pages and how they relate, plus how someone navigates between them. Get this wrong and no amount of visual polish rescues it.
- A content plan and inventory. An audit of what content exists, what is missing, what needs rewriting, and who is responsible for producing it. Content is the single most common reason projects run late, and almost always because nobody planned for it here.
- A functional specification and agreed scope. A written description of what the site does, feature by feature, and, just as importantly, what it does not do. This is the document that ends the "I assumed that was included" conversation before it starts.
- Key wireframes or prototypes. Low-fidelity layouts of the pages that carry the most risk or complexity, so structure and flow are agreed before anyone designs a pixel or writes a line of code.
- Technical and platform decisions. The CMS, the hosting, the integrations, the frameworks, and the reasons for each. Choosing these deliberately up front avoids the far more painful discovery of a wrong choice mid-build.
- A risk register. The known unknowns written down: the third-party integration nobody has tested, the legacy data that needs migrating, the stakeholder who has not weighed in yet. Named risks get managed. Unnamed risks become emergencies.
- A realistic budget and timeline. Costed against the actual scope above, not a number guessed before anyone knew what they were building.
Not every project needs all of these to the same depth. A brochure site needs less functional specification than a members' portal. But the shape holds: goals, users, structure, content, scope, technical decisions, risks, and a plan grounded in all of them.
Why skipping it costs more than it saves
The savings from skipping discovery are visible and immediate. The costs are invisible until they arrive, and they arrive as a group.
Without agreed scope, you get scope creep. Every stakeholder assumes their favourite feature is in, the list quietly grows, and the budget is gone before launch. Without a risk register, you get mid-build surprises: the integration that will not authenticate, the content that does not exist, the approval that never came. These do not announce themselves early because nobody went looking for them.
Without wireframes and information architecture agreed up front, you get rework. Work gets built, shown, rejected, and rebuilt, and rework is the most expensive way to make a website, because you pay for the same page two or three times. And without clear goals, you can arrive at launch with a site that is finished but does not actually serve the business, which is the most expensive failure of all, because the whole spend missed the point.
Every one of these traces back to a decision that should have been made in discovery and was deferred into the build, where it costs several times more to resolve.
How much of a project discovery should be
Discovery should be a modest share of the total project, not a large one. It is the thin slice at the front that de-risks the far larger spend behind it. The exact proportion scales with the project's complexity and risk: a straightforward brochure site needs only a light discovery, while a complex platform with integrations, migrations, and many stakeholders warrants a more substantial one.
We describe it to clients as insurance you actually collect on. You spend a small, defined amount to protect the majority of the budget from the failures above. When we look back at projects that went badly over budget, the overrun almost never came from spending too much on discovery. It came from spending nothing on it.
How to get the most from it
Clients get far more out of discovery when they come prepared, and the preparation is not onerous.
Bring the real goal, not the requested deliverable. "We need a new website" is a solution; "we are losing enquiries because people cannot find our services" is a problem we can design around. Bring the people who actually make decisions into the room, because a discovery signed off by someone without authority gets reopened later. Be honest about constraints, the fixed budget, the immovable deadline, the platform you are stuck with, so the plan is built around reality rather than around them.
And treat content seriously from the start. If you know who is writing it and roughly what it is, you have removed the single most common cause of delay before the build even begins.
Discovery is not the phase to skip to save money. It is the phase that decides whether the rest of the money is well spent. If you are planning a website build and want it to land on scope, on budget, and actually working for your business, get in touch.
