When a business website project runs into problems, the root cause is rarely bad design or poor coding. More often, it is a discovery phase that was skipped, rushed, or never really happened at all. Functional requirements were assumed rather than documented. Technical constraints were not discussed. What happens after launch was not planned. And by the time these gaps surface during development, fixing them costs significantly more than they would have if they had been addressed upfront.
This article covers the discovery questions that matter most before building a business website. It is written for small business owners, founders, and decision-makers in the UK who want to approach a web project with enough clarity to avoid the most common and expensive mistakes. The goal is not to make you a technical expert. It is to help you ask the right questions, recognise when a developer is guessing, and understand what a properly structured discovery phase should produce.
Why discovery matters before any code is written
Technical discovery is the process of translating what a business wants into what a website can actually deliver. It sits between a brief and a build, and its purpose is to make assumptions visible, resolve conflicting expectations, and establish a realistic scope.
A brief tells a developer what the business wants. Discovery figures out what that means in concrete technical terms and identifies the gaps between the two. Without it, developers estimate based on incomplete information, budgets get tight before work even starts, and the final site often does not match what was imagined because that image was never pinned down technically.
A useful way to approach discovery is to answer three core questions. First, what does the website need to do functionally, and what data does it need to handle? Second, what environment will it live in, and what does that environment require from a hosting and security perspective? Third, what happens after launch, and who is responsible for keeping it running?
When these questions are answered clearly during discovery, projects tend to come in on time and on budget. When they are not, scope creep accumulates, costs rise, and the final site requires expensive changes to work properly for the business.
Starting with what the website needs to do
The most productive place to begin is not with design or colour schemes. It is with the functional requirements. A website that generates enquiries works differently from one that processes orders, and differently again from one that hosts a membership area or delivers digital products. Each of these has distinct technical implications that affect platform choice, hosting specification, database design, and security posture.
For a UK small business, common functional requirements include displaying a service catalogue, capturing enquiries through a form, taking bookings or appointments, processing payments, managing a blog or resource library, protecting content behind a login, or integrating with an existing CRM or accounting tool. Each of these needs to be documented in enough detail that a developer can estimate accurately and build correctly.
Questions that help pin this down include: What happens when someone submits an enquiry? Does it go to email, a CRM, a database, or all three? Do you need the enquiry data to be searchable, exportable, or linked to a customer record? If you take payments, do they need to reconcile with your accounting software? If you store customer information, how long do you keep it and who can access it?
These are not abstract concerns. They determine whether the website needs a custom database, a plugin ecosystem, an API integration, or all three. Getting the answer wrong at this stage usually means expensive changes later. If you are planning a project with multiple systems involved, it helps to understand how to scope a small business website project without surprises before you commit to a development approach.
Choosing the right platform and hosting environment
Platform choice is one of the most consequential decisions in any web project. The main options for a small business website in the UK are a content management system like WordPress, a hosted platform like Shopify or Squarespace, or a custom-built solution using PHP, MySQL, and a LAMP stack or similar server environment.
Each has a different profile of cost, flexibility, maintenance burden, and technical skill required to manage it long-term. A WordPress site gives you full control and a vast plugin ecosystem, but it requires regular updates, security monitoring, and hosting that can handle the stack properly. A hosted platform reduces your maintenance overhead but limits what you can customise and ties you to the platform's pricing and terms. A custom PHP build gives maximum flexibility and clean code but requires an experienced developer to build and maintain it.
The discovery phase should establish which of these fits the business's current technical capability. If the person managing the website is not comfortable with updates, backups, or security hardening, that is a strong argument for a hosted platform or a properly managed WordPress setup with a maintenance contract. If the business needs deep customisation or specific integrations, a custom build or a headless CMS approach may be worth the extra investment.
Hosting is closely related to platform choice. For a small UK business, the typical decision is between shared hosting, a managed VPS, or a dedicated server environment. Shared hosting is sufficient for low-traffic brochure sites, but it becomes problematic if the site grows, runs resource-heavy plugins, or needs reliable email deliverability. A managed VPS or dedicated environment gives better performance and control, and it is easier to secure properly, but it costs more and requires either technical expertise or a managed service to keep it running safely.
DNS, email deliverability, and domain setup
DNS configuration is often treated as an afterthought, but it affects performance, email deliverability, and security in ways that are difficult to fix after the site is built. During discovery, it is worth understanding where the domain is registered, where DNS is managed, and whether the hosting environment is on the same provider or separate.
For a small UK business, common DNS issues include email going to spam because the domain lacks proper SPF, DKIM, and DMARC records, slow load times because DNS resolution is slow or the hosting server is geographically distant from the UK audience, and SSL certificate problems when the hosting environment is not configured correctly for the domain.
A practical check during discovery is to ask whether the current domain setup has been audited recently. If the website is on one provider, email is handled by another, and DNS is managed somewhere else entirely, there should be a clear written record of which records point where and why. This documentation prevents problems when things change and makes troubleshooting much faster.
API integrations and data flow between systems
Most business websites do not work in isolation. They connect to email systems, CRMs, accounting software, booking platforms, or third-party APIs. During discovery, it is worth mapping out every external system the website needs to communicate with, what data flows between them, and what happens when those systems change or go offline.
Common integration scenarios for UK small businesses include enquiry forms that populate a CRM, booking systems that sync with a calendar app, payment processors that generate invoices, and product feeds that update automatically. Each integration introduces a dependency that needs to be documented, tested, and maintained. If you are considering integrating multiple systems, reviewing how API integrations work for small businesses before committing to a specific approach helps you understand the technical scope and plan for failure scenarios.
If automation is part of the plan, the discovery phase should establish what needs to happen automatically, what the trigger conditions are, and what the fallback is if the automated process fails. Automated emails that go to spam, form submissions that disappear silently, or inventory updates that run out of sync are common problems when integrations are built without clear specifications and testing procedures.
SEO foundations that need to be planned from the beginning
Search engine optimisation is not a feature to bolt onto a finished website. The decisions made during development, from the URL structure to the page architecture to how content is managed, have a lasting effect on how easily the site can be found and indexed.
During discovery, questions worth raising include: Will the site be built with clean, semantic HTML that search engines can read? Is there a plan for XML sitemaps and canonical URL handling? Will the site use a proper heading hierarchy or will headings be styled arbitrarily? Will images have meaningful alt text, or will they be left empty? Will the site load fast enough to avoid Core Web Vitals penalties?
These are not advanced SEO topics. They are basic technical requirements that a competent developer should address as a matter of course. If a developer does not ask about them during discovery, that is a reasonable signal to ask them yourself or look elsewhere.
Security considerations that belong in discovery
Website security should be considered from the beginning, not retrofitted after a problem appears. The discovery phase is the right time to establish what level of security the site needs, what data it will handle, and what the consequences of a breach would be.
A basic business website that collects enquiries and does not store payment information still needs security measures. These include keeping the platform and plugins updated, using strong password policies for any admin accounts, implementing HTTPS with a properly configured SSL certificate, and setting up monitoring or logging so that suspicious activity is noticed quickly.
For websites that handle personal data, logins, or payment processing, the requirements are more stringent. UK GDPR compliance means considering data minimisation, secure storage, clear privacy policies, and proper procedures for handling data subject access requests. These are legal obligations, not optional extras, and they need to be planned into the build rather than treated as a checkbox after launch.
Maintenance planning and long-term ownership
Many small businesses commission a website without discussing what happens in six months or a year. Who updates the plugins? Who handles hosting renewals? Who responds if the site goes down on a Friday evening? These are operational questions that deserve answers during discovery, not after launch.
A practical maintenance checklist for a UK small business website should cover several areas. First, software updates including platform core, plugins, themes, and PHP version. Second, security monitoring including SSL certificate renewal, login attempts, and unexpected file changes. Third, backups including daily or weekly automated backups, off-site storage, and regular restore testing. Fourth, performance monitoring including page load times, Core Web Vitals scores, and hosting resource usage. Fifth, content and SEO maintenance including broken link checks, sitemap updates, and content freshness reviews.
If the business does not have someone who can handle these tasks reliably, it is worth discussing a maintenance contract with the developer or an IT specialist as part of the discovery process. The cost of a maintenance contract is usually significantly lower than the cost of emergency recovery or a rushed rebuild.
For businesses that need to demonstrate the value of IT investment to stakeholders, understanding how to build IT service reports that show business value can also be useful when budgeting for ongoing website maintenance alongside broader IT support.
Common mistakes in the discovery phase
The most frequent mistake is treating discovery as optional or rushing through it to get to the "real work" of design and development. This usually leads to scope creep, budget overruns, and a final site that does not match what was imagined because the imagination was never pinned down technically.
Another common error is confusing a design brief with a technical specification. Saying "I want a modern, professional website" tells a developer almost nothing useful. Saying "I need a site that can display a product catalogue of around 200 items, allow customers to request quotes through a form, and send those requests to our existing HubSpot account" gives a developer something to work with.
A third mistake is underestimating ongoing maintenance. Businesses often assume that once the website is built, the work is done. In practice, a website is a living system that needs regular attention to stay secure, fast, and functional.
A fourth mistake is not documenting the technical decisions that are made during the project. If the hosting provider, platform version, third-party services, and integration details are not written down somewhere the business can access, troubleshooting future problems becomes unnecessarily difficult and expensive.
Questions worth asking your developer or IT specialist
Before committing to a developer or agency, it is reasonable to ask how they approach the discovery phase and what they need from you to do it properly. Good questions include:
- What information do you need from me before you can give an accurate estimate? A developer who cannot answer this clearly may be guessing rather than assessing the actual scope.
- What technical decisions will you need my input on before development starts? Platform, hosting, integrations, and security level all need business input alongside technical advice.
- How do you handle changes to scope once development is underway? A clear change request process with transparent pricing protects both parties.
- What does your testing process look like before handover? Testing should include functionality, performance, security basics, and mobile responsiveness.
- What documentation will you provide when the site is complete? At minimum, this should include hosting details, platform credentials, and a summary of what was built and why.
- What ongoing maintenance options do you offer, and what is included? Understanding the maintenance offering before you need it is much better than scrambling for help after a problem.
- How do you handle security updates and what is your response time if something goes wrong? Response time expectations should be agreed in advance, not discovered during an emergency.
- What hosting do you recommend, and can you manage it on my behalf? If the developer cannot recommend or manage hosting, you need to know who will.
The answers to these questions tell you a lot about how a developer works and whether their process is likely to result in a site that meets your needs. A developer who is vague about discovery, unwilling to document requirements, or dismissive of maintenance is worth approaching with caution.
When it makes sense to hire help rather than attempt it yourself
For a very simple static website with a handful of pages and no functional requirements, it is possible to use a DIY platform like Wix, Squarespace, or the WordPress.com route without needing technical help. These platforms have improved significantly and are reasonable choices for very small businesses with minimal requirements.
However, if the website needs custom functionality, integrations with business systems, search engine visibility, secure data handling, or ongoing maintenance, the DIY route usually ends up costing more time and money than working with someone who understands the technical side properly from the start. The hidden costs of a poor foundation are high: slow performance, security vulnerabilities, poor search rankings, and the need to rebuild later.
A freelance IT specialist with web development experience can handle the discovery process, provide honest technical advice on platform choice, build or configure the site correctly, and set it up for long-term maintainability. For a UK small business that does not have an in-house technical resource, this is usually a better investment than trying to piece together a solution from templates and plugins.
What a well-run discovery process should produce
A good discovery process should produce several concrete outputs. First, a functional specification that describes what the website will do, what data it will handle, and how it will integrate with other systems. Second, a technical specification that describes the platform, hosting environment, security measures, and SEO foundations. Third, a clear scope document that defines what is included and what is explicitly out of scope. Fourth, a maintenance plan that covers updates, backups, monitoring, and who is responsible for each.
These documents take time to produce, and that time is worth paying for. They are the difference between a project that goes smoothly and one that becomes a source of stress and conflict. If a developer is willing to start work without a clear discovery phase, that is a risk worth weighing carefully before committing.
If you are planning a web project and want to work through the technical discovery with someone who takes a practical, no-nonsense approach to requirements, getting in touch early saves time and money later. A clear discovery phase sets the tone for the entire project and makes it much more likely that what gets built actually works for the business.