A reliable website partner does not sell only a design or a technology. They help define the goal, make their work transparent and leave your business in control of its accounts, content and data. Use the same brief, verifiable evidence and pre-agreed acceptance criteria to compare candidates fairly.
Start with a short but decision-ready brief
You cannot compare partners meaningfully if the task is simply to make a modern website. Describe the business objective, key users, current problems, initial content scope, languages and integrations, target schedule and budget range. State who in your organisation makes decisions and supplies material.
Ask each supplier to name assumptions, exclusions and risks. A good partner will challenge an oversized first release and suggest a sequence that publishes the most valuable part first. An unclear objective does not become clear just because the quote is fixed.
- Which business outcome should the site support?
- Which users and tasks matter most?
- What content will be kept, written or removed?
- Which systems must the site connect to?
- How will success be judged over 3–12 months?
Assess process and outcome, not just portfolio images
A same-industry case study can help, but the ability to solve a similar problem matters more. Ask for the starting point, the supplier's exact role, key choices, the hardest trade-off and the measured outcome. A screenshot says nothing about content quality, accessibility, performance or maintainability.
Open several delivered sites on mobile and use a keyboard. Check whether important information is easy to find, forms work and pages load stably. If search performance is part of the service, ask for reasoning grounded in official search guidance and avoid anyone promising a guaranteed number-one ranking.
A sound process names owners and decision points
Find out who leads the project, designs user journeys, writes and edits content, builds, tests and approves. One person may fill several roles in a small team, but accountability should still be explicit. Ask how often work in progress is reviewed and how feedback is documented.
Put decision points for structure, content, visual direction, functionality and launch into the schedule. This makes the cost and timing effect of changes visible before work begins. W3C recommends including accessibility goals in procurement and acceptance testing, not adding them at the end.
Set testable acceptance criteria
Words such as fast, accessible, SEO-friendly and secure are too vague without a test method. A contract can specify supported browsers and devices, WCAG version and level, critical journey tests, Core Web Vitals targets, indexability checks, form error states and backup restoration.
An automated report is not enough by itself. Agree what is tested automatically, what is checked manually and who fixes defects. Define the boundary for third-party services too: booking, chat, consent tools and embeds can weaken accessibility or performance even when the core site is sound.
| Area | Ask at least | Possible evidence |
|---|---|---|
| Content | Who writes, edits and approves? | Content plan and responsibility matrix |
| Accessibility | Which WCAG version and test scope? | Manual test report and remediation list |
| Performance | How is the target measured before and after launch? | Agreed page types and field monitoring |
| SEO | How are migration, URLs and indexation handled? | Redirect map and Search Console check |
| Security | Who patches, monitors and restores? | Maintenance description and restore test |
| Measurement | Who owns accounts and the event model? | Client-controlled administrator accounts |
Confirm ownership and an exit route before work starts
Your business should control its domain and receive agreed administrator access to the CMS, hosting, analytics, Tag Manager and Search Console. Define ownership of source code, design files, copy, images, licences and data, plus the package delivered when the engagement ends.
Vendor lock-in is not always wrong: a managed service can reduce client workload. It should be a conscious decision with known price, limits and exit terms. Ask how content and data are exported, accounts transferred, notice handled and migration assistance priced.
Maintenance reveals the real quality of the partnership
After launch, the site needs updates, monitoring, backups, user support and content development. Ask what the monthly or annual fee includes, what is billed separately, how quickly incidents are handled and how security issues are communicated.
A good partner also agrees a development cadence: which data is reviewed, who proposes improvements and how they are prioritised. Maintenance should be an understandable service description, not merely a charge for a server continuing to exist.
Score every candidate with the same model
Score quality and risk before comparing price against them. For a wider procurement checklist, use the website buying guide.
| Criterion | Example weight |
|---|---|
| Understanding of goals and users | 25% |
| Evidence across content, design and technology | 20% |
| Process, communication and resources | 20% |
| Quality, accessibility and maintenance | 20% |
| Total cost and contract terms | 15% |
Warning signs before signing
One gap does not automatically make a supplier unsuitable, but several unclear points in one proposal increase risk. Request written clarification and make sure material promises from sales conversations appear in the contract or project description.
- a guaranteed number-one ranking or sales uplift without baseline data
- technology is selected before needs are understood
- content responsibilities, testing or migration are absent
- your business cannot control its accounts or export its data
- change, maintenance or exit pricing is left open
- the supplier cannot explain its role or results in case studies
When you want a clear scope, transparent responsibilities and a website that remains under your control, see how we deliver websites.
Sources and further reading
The accessibility, search and quality criteria were checked against official W3C and Google guidance. The scorecard is a practical comparison model whose weights should reflect your project's own risks.
