The fastest way to compare web partners is to use the same brief and the same questions for each one. A useful proposal should show what problem is being solved, what will be delivered, who is responsible for each input, and how the finished website will be verified and handed over.
01
Start with the decision, not the style
“We need a modern website” is not yet a project goal. Modern can describe almost any visual direction. A stronger brief names the audience, what they need to understand, and the next action the business wants them to take.
“Our prospects understand the service after a sales call, but the current website does not explain the difference. We need qualified visitors to understand the offer and submit a useful enquiry.”
Ask each candidate how content structure, navigation and calls to action would support that decision. Their answer reveals more than a collection of visual references.
02
Compare written scope, not headline price
Two proposals can use the same label—“business website”—while including very different work. Compare them line by line. Count agreed pages and reusable templates separately. Check whether copywriting, translation, photography, CMS setup, forms, analytics, technical SEO and redirects are included or excluded.
Content
Who supplies facts, writes drafts, approves claims and handles translation?
Function
Which forms, CMS roles, integrations and states are included?
Review
How many consolidated rounds are included at each stage?
After launch
What correction period, training and maintenance are included?
A lower number is not automatically better value if the missing work later becomes change requests. A higher number is not automatically safer if responsibilities and acceptance criteria remain vague.
03
Read proof accurately
A portfolio can demonstrate taste, range and implementation skill. It does not automatically prove business results. Look for clear labels: commissioned client work, self-initiated concepts, live production sites, prototypes, or visual explorations.
For a real case study, ask what the partner actually owned, what constraints existed and which outcomes were measured. For a concept, judge the thinking and craft—but do not treat fictional testimonials, revenue lifts or search rankings as evidence.
04
Inspect the path from design to ownership
Ask who writes the production code, who checks it and what happens when the approved design meets real content or a smaller screen. If design and development are separate, identify the handoff owner and how implementation differences are resolved.
Before signing, record who owns the domain, DNS, hosting, source files, repository, CMS account, analytics property, fonts and third-party licences. The client should hold business-critical accounts wherever practical. The proposal should also define backups, launch responsibilities and the support period.
05
Seven questions to ask before choosing
- What business decision should the website help a visitor make?
- Which pages, templates and integrations are included in the signed scope?
- Who supplies, writes and approves the content?
- How many review rounds are included, and what counts as a new direction?
- How will responsive behaviour, accessibility, forms and performance be checked?
- Who owns the domain, hosting, accounts, licences and delivered files?
- What support is included after launch, and what becomes a new request?
You do not need a perfect answer to every question in the first call. You do need evidence that the partner notices the uncertainty, explains the trade-offs and puts the final agreement in writing.
The short version
Choose clarity over theatre.
A suitable web design partner understands the business decision, defines the scope and responsibilities, labels evidence honestly, plans responsive implementation and gives you a clear route to ownership after launch.
Discuss your website