Technical Discovery Questions Before Building a Business Website

Why the discovery stage decides whether a business website project succeeds

A business website project rarely fails because of bad code. It fails because someone started building before the brief was real. The hosting was assumed, the integrations were guessed, the audience was generalised, and the success criteria were never written down. By the time the design files come back, the project is already drifting.

Discovery is the stage where a freelance IT specialist or web developer turns vague business goals into a buildable specification. The questions asked here determine what stack to use, what to integrate, what to leave out, what the budget should cover, and what "done" actually means. Skipping it is the most expensive shortcut in web development.

This guide is written for UK small business owners, founders, agencies, recruiters, and technical decision-makers who are about to commission a business website and want to know what a thorough technical discovery conversation should cover before any code is written.

What "technical discovery" means in a website project

Technical discovery is the structured conversation between the client and the builder that turns business intent into technical requirements. It is not a sales call, a brand workshop, or a design briefing. It is the part where the builder asks uncomfortable questions about hosting, data, integrations, security, ownership, and scope, and the client answers honestly enough to commit to a build.

Good discovery produces three outputs:

• A scope document describing what the website must do, what it does not need to do, and what is out of scope for this phase.
• A technical specification describing the stack, integrations, hosting, performance budget, and security baseline.
• A delivery plan with realistic timelines, dependencies, and decision points.

Without those three documents, the project is a verbal agreement dressed as a contract. The first disagreement on cost, timeline, or feature usually traces back to a missing discovery conversation.

The business context questions a discovery call must answer first

Before any technical questions, the builder needs to understand what the business is trying to change with a new website. The answers frame every decision that follows.

• What job does the website do? Generate enquiries, take bookings, sell online, support existing customers, or act as a credibility layer for sales conversations.
• Who is the primary audience? Local trade customers, UK-wide consumers, B2B procurement teams, recruiters, or partners. Each audience implies different content, speed, and trust signals.
• What does success look like in six months? Not a vague "more traffic", but a specific, measurable outcome such as a number of qualified enquiries, a revenue target, or a defined ranking goal.
• What is the website replacing or improving? A blank slate, an outdated site, a generic template, or a platform that has stopped scaling. The answer changes the risk profile.
• Who is responsible on the client side? A single decision-maker, a committee, or a marketing lead who has to sell ideas internally. Approval cycles and revision rounds are decided here.

If a discovery call skips these questions, the technical answers that follow are guesses. The first scoping meeting should always start with the business, not the platform.

Technical discovery questions about hosting, domain, and infrastructure

Hosting is not a footnote. It is the foundation the website is built on, and the decision shapes performance, security, cost, and the build itself.

A practical discovery conversation covers:

• Where is the domain registered today? Registrar, account ownership, and whether the client has login access. Many projects are delayed by domain transfers because access was held by a former contractor.
• What hosting is in use, if any? Shared cPanel, managed WordPress, Plesk, a cloud VM, a dedicated server, or nothing yet. Each implies a different migration path and a different cost model.
• What are the expected traffic levels? A brochure site serving a few hundred visitors a month and an e-commerce site expecting seasonal spikes have very different hosting requirements.
• Where are the visitors located? UK-first traffic can be served efficiently from UK or nearby European data centres. International reach changes the CDN strategy.
• What are the uptime and recovery expectations? A small business site may tolerate a few hours of downtime. A site that drives active revenue usually cannot.
• Who will manage the server after launch? The client, the builder, or a third party. If no one is named, server maintenance becomes an orphan task.

The output of this section is a hosting recommendation with reasons, not a brand preference. The reader does not need a sales pitch, they need a clear answer to "is this the right place to run this site".

Discovery questions about the technology stack and codebase

Stack decisions matter because they lock in cost, maintainability, and the pool of developers who can pick the project up later. Discovery should test whether the chosen stack matches the project.

• What language and framework is the site written in? A custom PHP/MySQL build, a WordPress install with a theme, a Laravel application, or a static site with a headless CMS. Each implies a different maintainer profile.
• What dependencies does the project carry? Plugins, npm packages, composer packages, third-party services. Every dependency is a future security and update task.
• Where is the source code stored? GitHub, GitLab, Bitbucket, or on a developer's laptop. The client should own the repository, with their own account, not a contractor's.
• Is there an existing database, and what does it hold? A migration from an old CMS usually means data cleansing, mapping, and validation work that is not visible in the design files.
• How is the codebase tested? Manual smoke tests, automated test suites, or no tests at all. For a business-critical site, the answer affects long-term cost.
• Is documentation part of the deliverable? Architecture notes, deployment steps, credentials storage, and an admin handover document. If this is not in scope, the next developer will start from zero.

A sensible question to ask the builder is what the stack is good at and what it is bad at. Stack bias is normal; undisclosed stack bias is a project risk.

Discovery questions about integrations, third-party services, and data flow

Most modern business websites are not stand-alone. They are stitched together from a CMS, an email platform, an analytics tool, a CRM, a payment gateway, a booking system, and a chat widget. Each integration is a contract, an API key, and a possible failure point.

Useful questions include:

• Which third-party services must the website connect to? Stripe, PayPal, Google Analytics, Search Console, Tag Manager, Mailchimp, HubSpot, Salesforce, Freshdesk, or a booking platform.
• Where does contact form data go? Email, a CRM, a spreadsheet, a helpdesk, or a webhook. The path matters because lost enquiries are usually routing problems, not design problems.
• Are there any APIs the website must read from or write to? Stock systems, product feeds, internal databases, or partner platforms. These integrations drive cost more than design choices usually do.
• What happens when an external service is down? Does the checkout fail, does the form queue locally, or does the page degrade gracefully. The answer reveals whether resilience has been designed in.
• Who owns the API keys and account access? Every external service should run under the client's account where possible, with the builder added as a user, not the owner.

If the discovery conversation skips integration mapping, the first month after launch is usually a chain of small "the form is not arriving in my inbox" problems.

Discovery questions about performance, SEO, and search visibility

Performance and SEO are not bolt-ons. They are decided at the same time as stack, hosting, and content structure. By the time the site is in QA, it is usually too late to fix a slow database, a missing crawl layer, or a content model that blocks proper internal linking.

Discovery should produce clear answers on:

• What is the target page-speed budget? Core Web Vitals targets, the maximum acceptable Largest Contentful Paint on a mid-range mobile device, and the cost of hitting them.
• What is the URL and content structure? Flat hierarchies, location pages, service pages, blog categories, and how internal linking will be planned. A site that cannot be crawled cleanly will not rank.
• How is metadata handled? A content model that captures meta title, description, canonical, schema, and Open Graph fields per page, not a retrofit after launch.
• How is indexing notified? Sitemap generation, robots.txt, and submission channels such as IndexNow or Search Console. IndexNow is a free protocol that lets a site push new and updated URLs to participating search engines, which speeds up discovery compared with waiting for a crawl.
• Is the site prepared for AI search? Structured content, clean headings, and a generated llms.txt file that tells AI crawlers what the site is about. This is not a ranking trick, it is a way of being legible to answer engines.
• What analytics and tracking are in place? A first-party tracker, GA4, server logs, or a custom analytics layer. The discovery call should name the events that matter, not just the platform.

These questions are not theoretical. They decide whether a new business website is discoverable in the first three months or invisible for a year. The decisions made in the discovery document are usually the ones that determine whether the site ever earns organic traffic at all.

Discovery questions about security, access control, and compliance

Security discovery is the conversation most clients want to skip. It is also the one that prevents the most expensive incidents. A serious discovery call covers:

• Where are credentials stored? A password manager with shared access, a spreadsheet, or a developer's personal notes. The answer drives whether a credential rotation is part of the project.
• What access does the builder need, and for how long? Temporary admin access that is revoked at handover is healthier than permanent access that quietly persists.
• Is HTTPS and a valid certificate in place? Free certificates from Let's Encrypt are now standard. The discovery document should record who renews them and how.
• What is the backup and restore story? Frequency, retention, off-site storage, and a tested restore process. Backups that have never been restored are a hope, not a plan.
• Is there a vulnerability scanning routine? Scheduled dependency scans, server patching, and a process for applying critical updates. A site without a patching routine is usually the one that gets compromised.
• Are there compliance duties? UK GDPR, cookie consent, data processing agreements, and PCI scope if payments are involved. The website is usually the most visible compliance surface the business owns.

For a deeper look at defensive configuration for PHP-based sites, the practical guidance in PHP website security basics for non-technical business owners covers the kind of baseline that should be in any discovery document.

Discovery questions about content, ownership, and handover

Most handover problems are content and access problems, not code problems. Discovery should clarify:

• Who writes the copy? The client, the builder, or a copywriter. Word counts, tone, and approvals need to be in scope or they become change requests.
• Who supplies the imagery? Brand assets, product photos, headshots, and any licensed imagery. The licence terms should be checked before launch.
• What training is included? How the client edits the CMS, manages users, and publishes a blog post. Training is often the difference between a maintained site and an abandoned one.
• What is the handover package? Source code, credentials, documentation, deployment notes, and a recorded walkthrough. If this is not in scope, the next developer will charge for re-discovery.
• What happens after launch? A warranty period, a maintenance agreement, or a hand-off into the client's own care. "Done" needs a definition.

The questions above overlap heavily with the kind of practical scoping already covered in key discovery questions before starting a business website project, which is a useful companion read for anyone preparing for a first conversation with a freelance IT specialist.

Discovery questions about budget, timeline, and risk tolerance

Budget, timeline, and risk are uncomfortable topics that have to be on the table from the first call. Without them, the project slides into scope creep and missed deadlines.

• What is the realistic budget for this build? Not the ideal budget, the realistic one. Builders price differently, and a vague "small" budget forces a vague proposal.
• What is the deadline, and what is driving it? A trade show, a seasonal campaign, a contract requirement, or an internal milestone. Hard deadlines are real, but they imply trade-offs.
• What is the risk tolerance? A first version shipped in six weeks, or a polished version in four months. Each has a different cost and a different failure mode.
• How are change requests handled? A written change request process with cost and time impact. Without it, every small tweak is a negotiation.
• What is the payment schedule? Deposit, milestones, and final payment tied to deliverable acceptance. A clear schedule is the single best protection for both sides.

A good discovery conversation ends with a written summary. The client reads it back, signs it, and the build starts from a shared understanding rather than a verbal one.

When to ask for technical discovery help instead of running it yourself

Running a discovery conversation yourself is reasonable if the website is small, the stack is familiar, and the business goals are clear. The moment any of the following is true, the cost of a missed question grows fast:

• The site integrates with multiple external systems such as a CRM, a booking platform, and a payment gateway.
• The codebase is custom or has been built by multiple contractors over the years.
• The business has compliance duties tied to UK GDPR, PCI, or industry regulators.
• The site is a revenue channel, not a marketing brochure, and downtime is directly costly.
• There is no in-house technical owner, and the project depends on a single freelancer or agency.

In those cases, paying for a discovery engagement before a build often saves more than it costs. It is also a useful checkpoint if you are evaluating a freelance IT specialist and want to see how they ask questions. The quality of a builder's discovery call is usually a fair signal of the quality of the build.

If a redesign is the goal, an audit before discovery is often the right first step, and the framework in how to audit a business website before a redesign is a practical starting point for that conversation.

Getting practical discovery help for a business website

If you are weighing up a new build, a redesign, or a takeover of an existing site, a short discovery conversation usually saves more time than it takes. A clear scope written down before any code is committed is the cheapest risk control in any web project.

N. Cristea works with UK small businesses, agencies, and technical decision-makers on discovery, builds, and ongoing website maintenance. If you would like a second pair of eyes on a brief, a stack choice, or a project that has started to drift, you can start with the discovery questions framework or get in touch to discuss the project directly.