How to compare website quotes beyond the headline price

First make the proposals describe the same job

A quote for a website is a proposal about scope, responsibility and risk expressed as a price. If one supplier includes migration, content entry and integration testing while another includes only page construction, the totals are not yet comparable.

Ask each supplier to mark every requirement as included, optional, excluded or unresolved. Do this against the same short brief. It is more useful than asking both to promise a “complete website”, because that phrase leaves the expensive details undefined.

This article gives a comparison method, not a market price survey. The worked figures are invented to demonstrate arithmetic. They are not WebSoftLeader’s prices, regional averages or a recommendation to spend a particular amount.

Separate the website from the material it needs

Confirm who writes and enters the text, edits product data, supplies images and approves claims. “CMS included” does not tell you whether the supplier will load ten records or ten thousand. It also does not tell you whether your team can maintain the particular fields it needs.

For an existing site, ask which pages, downloads and addresses are being moved. For a multilingual site, identify the languages, the number of genuinely translated pages and who checks terminology. A translated menu with untranslated forms is a different deliverable from a complete customer journey in another language.

Do not turn every open question into a speculative feature. Some uncertainty is better resolved through a small paid investigation with a clear output, such as a data mapping and a tested sample connection. Compare the discovery deliverable and what happens if it reveals more work.

Ask what “complete” means for each milestone

The Scrum Guide’s Definition of Done makes completed work explicit through shared quality criteria. You do not need to adopt Scrum to use the practical habit of describing what must be demonstrably finished.

For a website, a screenshot might support visual approval. It cannot show that a payment callback is processed correctly or a request reaches the right team. Ask for the evidence appropriate to the deliverable: an editable page, a completed test submission, a migration sample or an observed recovery from failure.

Tie review discussions to those deliverables. A milestone named “development, 70%” is difficult to assess without a definition of the completed work. Where payments follow stages, the proposal should explain the deliverable and approval process for each stage rather than rely on the percentage alone.

Compare an agreed period of ownership

Choose a comparison period that matches the decision, for example the first year. Separate the initial build from recurring services and usage-based fees. Ask who pays each external provider and whether the account remains accessible if you change developers.

Include only the future work you actually intend to commission. A maintenance allowance is a planning assumption, not proof that a particular number of hours will be needed. If traffic, transactions or storage affect a fee, ask for the charging basis rather than a single unqualified annual total.

The lower initial figure does not produce a lower total in this example. That is the only conclusion the arithmetic supports. It says nothing about which supplier delivers better work, whether either allowance is sufficient or what your project should cost. Taxes, transaction fees and any other applicable charges would need their own agreed treatment.

Make quality work visible in the estimate

An assurance such as “fully tested” needs boundaries. Request the main customer journeys, the planned devices or browsers, the handling of known issues and the handover format. A useful test record says what was attempted, what happened and which version was checked.

Accessibility also has people and resource implications. W3C’s planning guidance includes budgeting for evaluation, training and ongoing monitoring. In your comparison, ask which accessibility target and evaluation work are included instead of treating an automatic score as the entire service.

For a CRM connection, ask about repeated deliveries and incorrect input. For a redesign, ask about old addresses and downloads. The relevant checks depend on the work being purchased. You do not need the same long test list for every small task.

Keep a decision record

• Record the agreed scope and the questions each supplier has answered.
• Separate assumptions from confirmed facts and set a review point for unresolved items.
• Ask how a change is estimated and approved before it is implemented.
• Confirm the access and documentation needed if another supplier takes over.
• Write down why the chosen proposal fits the first release, including any accepted limitations.

If the budget does not cover the full wish list, reduce the first release to a complete useful journey. Removing an uncertain secondary feature is usually a clearer scope decision than quietly omitting the checks needed for the primary journey to work.

Prepare a proposal that can be compared

Start with the website brief and the brief-writing guide. For a specific existing-system problem, use the integration brief so the estimate can identify the data, actions and acceptance checks involved. Current service prices are listed on the services pages.

Evidence and sources

Sources checked on 15 October 2026. The comparison table, questions and financial illustration are WebSoftLeader’s editorial method. No supplier performance or market price statistics are claimed.

• Ken Schwaber and Jeff Sutherland: the Scrum Guide. Supports the explanation of a shared Definition of Done, not a claim that every website project uses Scrum.
• W3C WAI: planning accessibility. Supports making accessibility resources and evaluation part of planning.