The WordPress Discovery Process: 12 Questions That Save Six-Figure Mistakes

The most expensive WordPress projects I have seen were not the ones with the biggest budgets. They were the ones where nobody ran a proper discovery. A retailer in the Midlands once spent close to ninety thousand pounds rebuilding a site that, on paper, looked like a forty-thousand job. The gap was not greed. It was a missing conversation in week one. Nobody had asked whether the new platform would talk to their warehouse system, and by the time someone did, the architecture was set.

This is the WordPress discovery process we run at WitsCode before we quote any build. Twelve questions, organised into five themes, that we walk through with every prospect, whether they are an SMB founder with an AI-generated prototype or an agency owner trying to tighten their own intake. Each question is here because skipping it has, at some point, cost somebody real money.

Audience and traffic: knowing who the site is actually for

A surprising amount of WordPress work begins with no clear picture of the visitor. Brand documents talk about personas in the abstract, but the discovery call is where you find out whether anyone has tested those personas against reality. This first cluster anchors technical decisions in audience behaviour, not aesthetic preference.

Who is the primary visitor and what are they trying to do in the first thirty seconds?

This forces a client to choose. If the answer is "everyone," that is a useful red flag. Sites built for everyone perform for nobody, and they balloon in scope because every stakeholder adds their pet feature. A good answer sounds specific and behavioural. "A facilities manager at a UK manufacturing site comparing three suppliers, who will read two case studies and then either book a call or close the tab." That sentence informs navigation, homepage hierarchy, and theme architecture. When the answer is "we have five audiences and they all matter equally," we are about to spend extra workshop hours narrowing before we can scope honestly.

What is your current traffic profile, including volume, sources, geography, and peaks?

Traffic profile drives hosting tier, caching strategy, image pipeline, and whether the site needs a CDN. A B2B firm doing four thousand sessions a month is a different brief from a publisher doing four hundred thousand, even if both ask for "a WordPress site." We want twelve months of analytics, not the rounded number the marketing director quotes from memory. Look for spikes tied to PR mentions, paid campaigns, or seasonal patterns, because those are the moments the site fails. A red flag is a client who cannot share analytics access, or who claims they do not track. The absence of data is itself a finding, and usually means discovery widens to include measurement before scoping is sensible.

What is the one number on this site that, if it doubled, would change your business?

I learned this from a former client running a recruitment platform. He answered without hesitation: "qualified applications per week." Everything we built afterwards laddered to that number. When you ask this and the room goes quiet, you have exposed that nobody has tied the site to a business metric. The good answer is concrete and tied to revenue or pipeline. Vague answers like "brand awareness" or "lower bounce rate" tell you the project is not yet ready to quote, because the success criteria do not exist.

Content and velocity: what changes after launch

A site is not finished on launch day. It is barely started. Content velocity, the rate at which a site changes after go-live, drives more architectural decisions than most clients realise, and it is the single biggest predictor of whether a build ages well or rots in eighteen months.

How often will this site change after launch, and who is the person doing the editing?

The honest answer separates a brochure site from a content engine. A solicitor's firm publishing one article a quarter has different needs from a SaaS marketing team shipping three posts a week. We ask who, by name and role, will be in the WordPress admin after launch. If that person is non-technical, then Gutenberg block patterns, custom post types with proper field labelling, and editorial guardrails matter more than they otherwise would. A red flag is "we will figure that out later," because later means after launch, and the editor inherits whatever was easiest for the developer to build.

How much existing content moves over, and what shape is it actually in?

Migration is where projects haemorrhage hours. A client may say "about two hundred blog posts to bring across," but until you have looked at the export, you do not know whether those posts carry inline Divi shortcodes, broken image references, or category structures that will not survive the move. We ask for a sample export during discovery, not after the contract is signed. If the existing content is on Elementor or Divi and the new build moves to native blocks, that is a migration project hiding inside a redesign, and the scope must reflect it. Clients who hand-wave this will be surprised by a change request in week six.

Integrations and stack: where the system actually breaks

WordPress can be made to talk to almost anything. The question is whether the things on the other end will reciprocate. Three discovery questions live here, and each of them has saved a project from a costly mid-build pivot at least once.

What systems must this site talk to, and have you read their API documentation?

The integration question gets harder the more confidently it is asked. A client who says "we just need to connect to HubSpot, Salesforce, our ERP, and a custom inventory system" is describing four projects, not one. For each named system we ask whether they have the API documentation in front of them, whether the API is open or gated behind an enterprise tier, and whether anyone on their side has written code against it before. The most expensive failure pattern in my career has been integrations assumed in week one and discovered impossible in week eight. The CRM is almost always the limiting factor, not WordPress. If the client cannot produce documentation links during discovery, we add a paid technical spike to the proposal rather than guess.

What does your hosting, DNS, and email stack actually look like today?

This question sounds boring. It is not. A site on a shared host, with the registrar holding DNS and a third party running email, is a site where any of three vendors can take you down on launch day, and you will not know which to call. We map the stack on a single page during discovery, covering registrar, DNS, host, mail, CDN, and any reverse proxies or security layers in front. The red flag is a client who does not know who hosts their existing site or who controls DNS. We have had launches delayed by a week because nobody could log in to the registrar a former employee set up four years ago.

Is there an existing prototype, AI build, or half-finished project we are inheriting?

This question has become essential. A meaningful share of our prospects now arrive with a Lovable, Bolt, or v0 prototype, or a half-finished WordPress site that someone in-house started and abandoned. We are, in our own framing, the last-mile developer for vibe coders, which means discovery has to honestly assess what is salvageable. Sometimes the prototype is a useful spec and we keep the design language. Sometimes the underlying code is so brittle that rebuilding from scratch is faster than refactoring, and saying so early is kinder than billing for it later. Pretending an inherited mess does not exist is how scope creep starts on day one.

Compliance and risk: the questions that protect everyone

UK and EU clients live under the UK GDPR and, depending on their customer base, the EU GDPR as well. American SMBs increasingly fall under state privacy laws that look more like GDPR every year. This cluster of questions is not legal advice, but it is the discovery work that makes legal advice useful when the client gets it.

What personal data does this site collect, and on what lawful basis?

We walk through every form, every tracker, every embedded service, and every third-party script that touches a visitor. The Information Commissioner's Office treats IP addresses, cookie identifiers, and device IDs as personal data in many contexts, not just names and email fields. For each category of data, the client should be able to state a lawful basis under Article 6, whether that is consent, contract, or legitimate interest. A red flag is the answer "our privacy policy covers it," because a privacy policy is the output, not the analysis. We have stopped builds at this stage when the client could not name the lawful basis for marketing tracking, because launching a site that quietly breaks the law is not a service we offer.

Who owns security incidents, backups, and uptime when something breaks at two in the morning?

The answer dictates whether the build includes a managed care plan or hands off to the client's team. We need to know who has the pager, what their response window is, and whether they have ever actually restored a backup. A small business owner who says "my nephew handles IT" is telling you something important. So is the agency that says they will manage it themselves but cannot describe their incident process. We cost the project differently depending on the answer, and the contract names the responsible party in writing.

Growth and ceiling: does the build survive what comes next?

The final cluster of questions is about time. WordPress sites we built five years ago are still running, but the ones that aged well are the ones where someone asked, in discovery, what the world would look like in two years.

Where do you expect to be in twenty-four months, and does this build survive that?

If the client expects to triple revenue, add three product lines, and expand into Germany, the build needs to support multilingual content, a more complex taxonomy, and probably a different hosting tier. If the client expects steady-state, we build leaner and save them money. The good answer is specific. "We are aiming for fifty per cent year-on-year growth and a second product launch in Q3 next year" is something we can plan against. "We just want a nice site" is a request to be helped toward a better question.

What is the one decision you do not want to revisit in eighteen months?

This is the closing discovery question, and it is the one that surfaces the deepest commitments. Some clients answer with platform choice, some with theme architecture, some with the integration partner. Whatever they say, we write it down and design around it, because that single answer is usually the load-bearing decision of the entire build. A client who cannot answer it has not yet thought about the project as something they will live with, and we work with them on that framing before we send numbers.

What happens after the twelve questions

A proper discovery is not a form. It is a structured ninety-minute conversation, sometimes split across two sessions, with a written brief both sides sign off before any quote is issued. That brief becomes the boundary against which scope changes are measured, and it is the single largest reason our projects come in on budget while much of the industry does not.

If you are an SMB owner staring at a half-built site, an inherited AI prototype, or a quote that feels suspiciously round, this is the conversation that tells you whether the project is ready to build or needs another week of thinking. If you are an agency owner reading this to tighten your own intake, take whichever questions are useful and ignore the rest.

When you are ready to run this discovery against your own project, we offer it as a standalone engagement before any build proposal. Book a discovery call with WitsCode and we will walk you through the twelve questions, share the written brief, and tell you honestly whether the project is ready to quote or needs a smaller piece of scoping first. Six-figure mistakes do not announce themselves. They get baked in during the week nobody asked the right question.