Paid Discovery: A Low-Risk Way to Start a Website Project (And Test the Fit)

Written by

Paul Edwards

in

,
Paid Discovery: A Low-Risk Way to Start a Website Project (And Test the Fit)
Paid Discovery: A Low-Risk Way to Start a Website Project (And Test the Fit)
0:00
–:–

If you’re not 100% sure what your website project will actually involve, you’re not alone. What looks like a straightforward job at first is often anything but.

Most websites carry a bit of history. Custom snippets dropped in over the years. Plugins nobody can quite explain. Extra CSS piled on. Fixes layered over older fixes. That history has a habit of making “simple projects” a lot less predictable than they first appear.

A paid discovery phase helps reduce risk before you commit to a bigger-budget rebuild or redevelopment. It’s an agreed number of hours where I audit what you’ve got, investigate how the site is put together, diagnose issues, prioritise what matters, and give you a decision pack you can move forward with.

You can use that internally, or hand it to your chosen agency or freelance web designer. Either way, you’re not guessing and that’s an incredibly positive first step towards a successful project.

Another important benefit is that discovery lowers the cost of getting started. Instead of paying a sizeable deposit before you’ve got clarity, you make a smaller, contained investment first. That gives you answers, direction, and a useful brief before bigger decisions are made.

There’s also a valuable side benefit. Discovery is a very effective fit test. If it turns out we’re not the right fit, or the next step is different from what you expected, you can stop there and still walk away with something useful.

Discovery isn’t about buying a plan. It’s about buying down risk.

Why website projects feel risky (and why that’s rational)

Most website projects don’t go sideways because of a design decision such as someone chosing the wrong button colour. They go sideways because everyone commits to a big chunk of work before anyone has proper clarity on what’s really needed.

That risk gets even higher when you’re dealing with one of these common situations.

You’re deciding whether you need a rebuild, but you don’t want to gamble with budget, time, and internal attention. You’ve got performance or conversion issues, and you can’t tell whether the cause is technical, content-related, tracking-related, or just the slow buildup of small issues. Or you’re moving on from another agency or contractor and you want continuity, not another reset.

This isn’t just a “web projects” thing. In broader project work, poor planning and scope change are consistently high on the list of failure drivers. One PwC global project management survey (as cited by Safran) reports 39% of failures linked to poor estimates in the planning phase, and 41% linked to changes in scope mid-project.

That lines up with what people experience on websites. When the early assumptions are wrong, everything downstream gets more expensive.

The goal isn’t a report. The goal is fewer surprises.

What a paid discovery phase is (and what it isn’t)

With my web consultant hat on, I’ve already revealed that I think that ring-fencing a block of time for discovery works well. We agree a set number of hours up front that’s commensurate with the complexity of your situation, the level of risk, and the size of the website we are auditing.

Some clients worry discovery is “lost money”, or that it delays “real progress”. That’s often down to web professionals not explaining the process clearly.

Discovery isn’t a vague research phase where you pay for someone to think out loud. It also isn’t a sales trick designed to lock you into a bigger project. It’s structured, practical work designed to answer the questions that matter, quickly and clearly.

Sometimes discovery produces a clearly defined plan. Sometimes it produces a short list of fixes and a clear recommendation on what not to do. Either outcome is a win, because the goal isn’t paperwork. The goal is clarity and a sensible next step.

And there’s a second but no less valuable benefit here. The earlier you find issues, the easier they are to address. There’s a well-established pattern across engineering and delivery work that late discovery costs more than early discovery. NASA even has a published study on “error cost escalation” across the project lifecycle, showing how costs rise the later you find and fix problems.

You don’t need to care about aerospace projects to take the point. It’s the same idea: catching the real problem early is cheaper than working around it when you discover it much later into a project.

Why discovery is also a relationship test run

A website project isn’t just technical delivery. It’s the establishing and building of a working relationship, a relationship that is pivotal in whether the project feels calm or painful. Having the right person on board where communication styles are complimentary to each other, is essential for the success of a project.

  • Discovery gives you a chance to test how you and your chosen agency or freelancer work together:
  • Do you feel clearer after a conversation, or more overwhelmed.
  • Are problems explained in plain English, or hidden behind jargon.
  • Are decisions documented, or do they disappear into a Slack thread and never get seen again.
  • Do you feel pressured, or supported.

If the fit is good, you’ll notice early. Priorities become obvious. Decisions get made faster. The next phase stops feeling scary. If the fit isn’t good, you’ve bought yourself an early exit with minimal opportunity cost.

This is a test run. Not just of the website, but of how it feels to work together.

What you get at the end (a decision pack, not fluff)

At the end of discovery you get a practical decision pack. It’s designed to be something you can use, not something you file away and forget.

You’ll come away with a plain-English summary of what assets you have, their condition, and what’s most likely driving any issues you’re seeing. You’ll also get a prioritised set of recommendations, so you can see what needs doing now, what can wait, and what might be optional.

Where it’s helpful, I’ll also give you a couple of sensible routes forward. That might be “stabilise and tidy up what you have”. It might be “fix performance first, then revisit design”. Or it might be the more uncomfortable answer, which is that the foundations are too compromised and a rebuild is the most cost-effective route.

Either way, you’re not guessing. You’ve got enough clarity to choose your next move.

A rebuild is sometimes the right answer. It’s just a terrible thing to guess.

What happens next: fix, improve, redesign, or walk away

Discovery keeps your options open.

If you want me to implement the work, great. Discovery makes that smoother because we’re no longer debating what the work is. We’ve already done the thinking and agreed the priorities, so delivery becomes far more straightforward.

If you want your internal team to implement it, that can work too. If you want a different supplier to implement it, you can do that as well. You won’t be starting from scratch, and you won’t be relying on someone else to rediscover everything the hard way.

This is also why discovery is such a good fit for overstretched teams. It creates momentum without forcing commitment.

And this loops back to opportunity cost. The longer a project drifts in uncertainty, the more it costs in attention and delay. As PMI puts it, “If you only quantify one thing, quantify the cost of delay.”

The real cost isn’t the work you do. It’s the work you do instead of the right work.

When discovery leads to web design and development (and when it shouldn’t)

Sometimes discovery confirms that a redesign or rebuild is the right call. When that happens, it tends to be a relief, because you’re no longer trying to breath life into something that isn’t responding.

Other times, discovery shows that a rebuild isn’t the first lever to pull. You might not need a new website at all. You might need performance work, conversion work, content clarity, or simply stability and proper maintenance so the site stops feeling fragile.

Discovery stops you from doing the expensive thing first, just because it feels like the obvious thing. I can think of more than a few clients that came to me where they had kept layering up paid services to try and improve site performance rather than just fixing the problem. A short audit helped us identify a handful of paid services that could be removed if we carried out some technical improvements to help performance.

It also makes any design and development work far more grounded. Instead of building based on opinions and preferences, you build based on real constraints, real priorities, and a clear definition of success.

How to book discovery (and what I need from you to start)

If you’re facing a rebuild decision, performance or conversion issues, or a handover from another supplier, a timeboxed discovery phase is usually the lowest risk, most practical way to start.

To begin, I’ll ask for a small amount of context. I want to know what “good” looks like to you, what’s currently painful, and what constraints we need to respect. Then we agree the timebox and the output. From there, I do the work, and you get the decision pack.

If we’re a good fit, you’ll know quickly, because the next phase becomes straightforward. If we’re not, you still leave with something useful, and you’ve avoided committing to the wrong relationship.

If you would like to discuss research and discovery for your next project let’s have a conversation, call me on 01903 527927 or get in touch via my contact page.

Appendix: links mentioned