Do not compare two website totals until you know they purchase the same outputs. “A ten-page bilingual website” might mean design alone, design and development, or entry of supplied text without writing it. One proposal may include migration, testing and training while another leaves those tasks to the client. Normalize scope and assumptions before comparing price.
This is a buying method for a business website, not a market price guide. A responsible estimate needs pages, functions, content and dependencies. The purpose is neither to favor the highest quote nor to choose the lowest automatically. It is to understand what you receive and what you must arrange separately.
Request one shared deliverables matrix
Give suppliers the same questions and ask them to mark each item included, excluded or unresolved, with a brief explanation. Do not interpret an empty cell as agreement. If an answer says “as required,” ask who decides the requirement and how it changes scope and cost.
| Item | Clarification required |
|---|---|
| Pages and templates | Content instances versus distinct layouts |
| Design | Mobile states, interactions and handover files |
| Content | Writing, editing or entry of finished copy? |
| Languages | Translation, review, layout and entry responsibilities |
| Development | CMS, editable fields, functions and integrations |
| Migration | Content, assets and legacy addresses |
| Testing and launch | Scenarios, evidence and release authority |
| Handover and support | Accounts, training, defects and maintenance limits |
Website Design concerns page experience and implementation specifications. CMS Development concerns the agreed build and editing system. Buying design does not automatically purchase a launched website; having a live site does not prove your team can maintain its content.
Write acceptance that can be observed
Replace “professional contact form” with an outcome: a visitor submits in either language, required-field errors are explained, and the request reaches the approved destination. That can be tested and estimated. GOV.UK describes acceptance criteria as outcomes used to check whether a user need has been met. User-story guidance.
Where functions remain unresolved, Product Discovery and Requirements can reduce uncertainty. A small definition phase may be more useful than a fixed quote for a large unknown, provided its outputs are explicit and usable in the later implementation decision.
Hypothetical example: the same headline, different purchases
A company receives two proposals titled “ten-page bilingual website.” This is an illustration, not actual LAB quotations or market prices. Proposal A includes four templates, client-supplied text entry and an email enquiry form. Proposal B includes six templates, editorial work, both-language entry and an integration with an existing system, including delivery tests.
Do not conclude that B is better without asking whether the extra templates are needed, whether approved copy already exists and whether the integration is necessary now. A may fit after a clear review scope is added; B may be appropriate if its additional work is genuinely required.
The comparison then reveals that one supplier assumes the client will move downloads, while the other assumes an established hosting account. Add both assumptions to the matrix and request missing options on the same basis. The difference between two unrelated totals is not a demonstrated saving.
A useful outcome is a common mandatory scope with separately priced options. Suppliers may propose different technical approaches, but the business should still be able to identify the same tasks, ownership and acceptance outcomes in each response.
Account for approvals and changes
A project can stall because nobody owns the copy, not because a developer is idle. State what the supplier needs, who reviews it, how feedback is consolidated and what a revision round includes. Fixing a deviation from an approved requirement differs from introducing a new feature after approval.
Request a simple change process: describe the request, its consequences for outputs, timing and cost, and obtain approval before implementation. This need not become bureaucracy. It prevents a passing conversation from becoming a misunderstood commitment. Equally, “out of scope” should not conceal a defect that prevents an agreed output from working.
Compare life after launch
Who controls the domain, hosting and CMS accounts? Which licences recur? Can content be exported? Who maintains extensions? How do defect correction, support and new features differ? Get answers without assuming that a build package includes indefinite operation.
For Quality Assurance, define the pages, tasks, devices and languages covered and how blocking defects are handled. “Comprehensive testing” alone says little about coverage. A credible schedule also depends on content, access and approvals, not merely the preferred date of either party.
Decide after scope is comparable
Compare clarity, suitability, verifiable evidence of capability and operating responsibility alongside price. Challenge promises unrelated to inspectable deliverables, such as guaranteed first-place rankings or a fault-free future. Ask suppliers to identify dependencies they cannot control.
Before approval
- Mandatory and optional work is separated in each proposal.
- Languages, templates and content instances are counted clearly.
- Writing, translation and factual approval responsibilities are assigned.
- Integrations, accounts and recurring charges are known or explicitly unresolved.
- Acceptance criteria, changes and constraints are documented.
- Handover covers the materials and access needed to operate the agreed site.
Frequently asked questions
Is fixed pricing always preferable?
It suits understood scope and clear assumptions. For unresolved functions, a conditional estimate or discovery phase can be more honest than a fixed total containing hidden exclusions.
Should we request extensive technical detail?
Request details that affect outputs, ownership, cost and maintenance. You do not need to evaluate every software library to understand the purchase.
Does the number of design rounds indicate quality?
Not alone. What each approval covers, how feedback is consolidated and how requirements failures are corrected matter more.
Is a defect warranty the same as maintenance?
Do not assume so. Ask for the definition, duration and scope of each, including what happens when another party modifies the site.
Make the quotation comparable
Share the deliverables matrix and unresolved questions with LAB. Request separate descriptions for design, development, content, testing and handover. That supports a more informed decision than comparing totals covering different work.
Sources
- GOV.UK: acceptance criteria in user stories, reviewed 26 October 2026. This article makes no market-price estimates.
