Define the job the website must do
Write a one-page brief before comparing agencies. Identify the priority customer, the problem they are trying to solve, the services or products that matter most and the action the website should make easier. Include known constraints such as launch date, integrations, regulated claims, languages and internal approval capacity.
Separate essential requirements from preferences. A reliable enquiry path, accurate service information and ownership access are essentials. A particular animation or layout is usually a preference. This distinction keeps the project focused when budget or timing requires trade-offs.
Describe success in business terms. Examples include more qualified enquiries, a faster quotation journey, easier publishing, improved direct bookings or fewer repetitive support questions. Traffic or a new visual style can support the outcome but should not replace it.
- Priority audiences and the decision each must make
- Required pages, functions, integrations and content owners
- Commercial action and measurement plan
- Budget range, dependencies and genuine deadline
Ask each agency to explain its thinking
A strong agency should be able to restate the business problem and explain the proposed information architecture, customer journeys and content responsibilities. Ask what evidence shaped the recommendation and which assumptions still need validation.
Review two or three relevant projects in depth. Ask what the team was responsible for, which constraints existed, how the result was measured and what changed after launch. A screenshot cannot show accessibility, performance, lead quality, maintainability or whether the agency actually delivered the work described.
Meet the people who will do the work. Clarify who leads strategy, design, development, content, SEO, quality assurance and communication. A clear small team can be a better fit than a large agency when ownership is direct; the reverse can be true when the project needs specialist capacity at scale.
Compare scope and price on the same basis
Request a written scope that names deliverables, review rounds, content responsibilities, migration work, analytics, training, launch support and exclusions. A lower proposal may omit copy, redirects, testing, hosting or integration work that appears elsewhere as a separate cost.
Ask what can change the price and how additional work is approved. Fixed price can suit a well-defined project; a phased or time-based model can suit discovery-heavy work. The important point is that assumptions and decision points are visible before work begins.
Compare the cost of ownership, not only the launch fee. Include hosting, licences, maintenance, support, future editing and the effort required from the business. Avoid a technical setup that only the supplier can operate unless that dependency is deliberate and documented.
Protect ownership and access
Confirm who owns the domain, website code or platform account, design files, written content, photography, analytics, tag manager and advertising accounts. The business should have appropriate administrative access and know where critical credentials and recovery methods are held.
Ask how the website can be exported, transferred or maintained by another qualified supplier. Some managed platforms intentionally limit source access; that can still be a valid choice when the limitation, pricing and exit path are understood in advance.
Record third-party licences and content permissions. Stock imagery, fonts, plugins and data services may have ongoing terms. Real customer reviews, team photographs and case-study claims should be used only with accurate context and appropriate permission.
Evaluate accessibility, search and performance as product quality
Ask how the team handles semantic headings, keyboard navigation, focus states, labels, contrast, alternative text and error messages. WCAG provides a shared accessibility standard, but a checklist does not replace testing real journeys with different devices and input methods.
For search, expect crawlable navigation, descriptive page titles, one clear main heading, useful content, canonical URLs, redirects for replaced pages and an XML sitemap. Google's Search Essentials emphasise making content accessible and helpful; no agency can guarantee a ranking.
Performance should be considered during design and development, not added at the end. Ask how images, fonts, scripts and third-party tools are controlled and how Core Web Vitals and real mobile journeys will be checked. A fast empty page is not useful, but visual polish should not create avoidable delay or instability.
- Keyboard and touch navigation through the main journeys
- Readable contrast, labels, errors and alternative text
- Crawlable pages, metadata, canonicals, redirects and sitemap
- Mobile performance, layout stability and responsive interaction
Plan content, measurement and launch before design approval
Decide who supplies facts, writes copy, approves claims and prepares photography. Placeholder text hides layout and decision problems. Review real content in the design early, especially long service names, proof, pricing context, legal information and mobile calls to action.
Define the important events and test them only when the intended action succeeds. Preserve consent choices and avoid counting a button click as a delivered lead. Record the pre-launch analytics baseline and annotate the launch so later comparisons have context.
Request a launch checklist covering forms, email delivery, phone and WhatsApp links, redirects, index controls, metadata, structured data, security, backups and browser/device testing. Agree who monitors the first days and how urgent defects will be handled.
Use a shortlist scorecard and recognise red flags
Score each shortlisted agency against business understanding, relevant evidence, proposed journey, delivery team, accessibility, search foundations, measurement, ownership, support and total cost. Weight the criteria according to the project rather than assigning every item equal importance.
Treat guaranteed rankings, invented performance claims, vague ownership, pressure to sign immediately and a refusal to explain dependencies as warning signs. Also question proposals that promise every possible feature without discussing priorities, content or maintenance.
Choose the team whose process makes decisions clearer and risks visible. Chemistry matters because feedback can be difficult, but trust should be supported by a written scope, realistic responsibilities and transparent evidence.