How I approach technical discovery for new projects

How much of your last web project budget went on things that didn't need building? The most expensive mistake in web development is building the wrong thing. Not a bug, not a performance issue, not choosing the wrong framework, building something that doesn't actually solve the problem the client has. That's why every project at Innatus Digital starts with a discovery phase, and why I won't skip it even when clients are keen to get straight into development.

What discovery actually involves

Our discovery phase typically runs two to four weeks, depending on complexity. It covers four areas: understanding the business problem, auditing what exists, defining the technical approach, and scoping the build.

We start with conversations. What are you trying to achieve? Who are your users? What's working on your current site and what isn't? What does success look like in six months? These aren't perfunctory questions, the answers shape every decision that follows. A client who needs to generate leads has fundamentally different requirements from one who needs to sell products, even if both want "a new website."

Then we look at what exists. If there's a current site, I audit it, performance, accessibility, SEO, content structure, analytics data. If there are existing systems that need to integrate (CRM, ERP, stock management), we document the APIs and data flows. If there's content to migrate, we assess the volume and format. None of this is glamorous work, but it surfaces the constraints and complexities that would otherwise ambush us mid-build.

Choosing the stack

With the problem understood and the constraints mapped, I can make informed technology choices. Should this be a headless CMS build or a traditional one? Does the e-commerce requirement warrant a dedicated platform or can it be handled with a lighter solution? What hosting environment makes sense for the expected traffic patterns? We write these decisions up with reasoning, so the client understands not just what I'm recommending but why.

I'm stack-agnostic in the sense that I don't force every project into the same technology. I have preferences, Next.js and Sanity for content-driven sites, BigCommerce or Shopify for e-commerce, Laravel for bespoke applications, but those preferences give way to project requirements when they should.

The deliverable

At the end of discovery, the client gets a document that covers: the technical architecture, the platform and tool choices with reasoning, a content model if applicable, a breakdown of features into phases, a realistic timeline, and a budget. This document becomes the reference point for the entire project. When scope questions come up mid-build (and they always do), I can refer back to the discovery document and make decisions based on what was agreed rather than guessing.

Why it's worth paying for

Discovery typically costs between £2,000 and £5,000. That sounds like a lot to spend before any code is written, but consider the alternative: starting to build without a clear plan, discovering three weeks in that a critical integration doesn't work the way everyone assumed, and either absorbing the cost of rework or having an uncomfortable conversation with the client about additional budget. I've seen projects at other agencies go 50% over budget because discovery was skipped. Spending 5% of the budget upfront to de-risk the other 95% is a trade I'll make every time.

If you've got a project in mind and want to understand what it would take to build it properly, discovery is the place to start. Get in touch and I'll walk you through how it works.