What To Expect From a Paid Website Discovery Process

Why you can't rush the website discovery process

Rushing discovery is one of the most expensive mistakes a web project can make, and it rarely looks like a mistake until you're three months in and circling decisions that should have been settled on day one.

Discovery is where you get to ask "are we solving the right problem?" before momentum takes over. It's where you find out that the page leadership insists drives the most revenue is actually underperforming, while a page nobody talks about is doing most of the heavy lifting. It aligns your internal team, your developers, and your designers around the same understanding of your audience before anyone writes a line of code.

We've seen what happens when that step gets skipped. A client once walked away from our discovery findings because another agency promised a faster path. That agency skipped the internal review, ignored the user research, and built something that didn't work for the client or their audience. The client came back months later to fix it, which cost significantly more than doing it right the first time would have. If you want the full story, it's here: From Walkaway to Win: How Our Website Discovery Process Saved the Day.

Skip it or rush it, and you pay for it in rework, scope creep, and a site that looks great but doesn't move the business forward.

What to expect from discovery at Solspace

Discovery at Solspace is a working phase, not a presentation. We're not here to show you how clever we are. We're here to learn how your business actually runs, where your current site helps or gets in the way, and what the new site needs to do differently.

Here's how the process typically unfolds.

Kickoff meeting

We start by bringing the right stakeholders into the same conversation, leadership, marketing, whoever has a real stake in the outcome. We want to understand why this project exists now, what prompted it, and what success looks like six months after launch, not just on go-live day. That last question tends to reveal a lot. Most project briefs define success as "launching on time." The businesses we work with long-term define it as measurable outcomes.

Internal site review

Before anyone talks about the new site, we spend real time with the current one. We walk through how it's structured, how content flows, and where teams feel friction. We ask which pages people assume are performing well, and then we check. Teams are often surprised. The pages everyone points to in meetings are frequently not the pages actually driving leads or revenue. We use that gap to protect what's working instead of rebuilding it unnecessarily.

Analytics review

Qualitative input tells you what people think is happening. Data tells you what's actually happening. We look at how users move through the site, where they drop off, and which pages earn attention versus which ones bleed it. This gives the project anchors in real behavior, so design and development decisions aren't based on opinions and gut feelings.

Stakeholder interviews

Different people in your organization feel the site's impact differently. The sales team knows which pages create confusion in demos. Support knows which sections generate unnecessary follow-up. Marketing knows what they wish they could update but can't. These conversations surface friction that rarely makes it into a project brief but almost always matters to the outcome.

User context and personas

We work with you to define who the site actually serves and what those users come to do. This isn't a box-checking exercise. Navigation structure, page hierarchy, content tone, and calls to action all flow from a shared understanding of your audience. Without it, every design decision becomes a debate.

Content strategy

We look at what content you have, what's missing, and how it should be organized. More often than not, the problem isn't a lack of content. It's that the content you have isn't structured to guide users toward a decision. This phase also surfaces what needs to be refined or rewritten before it moves to a new site, so you're not migrating problems.

Technical context

We need to understand what you're building on before we can tell you what's realistic. Platform, third-party integrations, anything that's already feeling stretched. You don't need to make architecture decisions in discovery, but you do need an honest picture of your constraints so the recommendations that follow are grounded in reality.

Defining the next phase

Discovery shouldn't end with a pile of notes and no direction. We close it by laying out what we learned, what matters most, and how the next phase should take shape. Your team leaves knowing where this is headed. We leave ready to move.

Why we charge for the website discovery process

When discovery is free, it gets treated as disposable. The real work doesn't start until the contract is signed, and by then, the assumptions that should have been challenged are already baked in.

We'd rather take the time to do this properly and give you something genuinely useful, whether you continue with us or not. 55% of our long-term clients came to us originally to solve an urgent problem. Discovery is often where we first earn that trust, because we're honest about what we find, even when it complicates the project scope.

If your current agency offered to do discovery for free, it's worth asking what they actually did with that time. And if you're evaluating partners now, the answer to that question will tell you a lot.

Ready to start yours? Get in touch.