Website quotes: compare deliverables, responsibilities and ongoing costs
A practical website quote checklist with a scope comparison table, real project examples and questions about content, integrations, handover and maintenance.
Two website quotes are only comparable when they describe the same work. A page count alone will not tell you whether writing, a booking integration, migration of existing URLs or post-launch support is included.
Start with a common brief, then compare the deliverables and assumptions line by line. This guide gives you a structure for that conversation without treating a low price, a particular technology or a company size as proof of quality.
Prepare the information needed for a useful proposal
Describe your business, audience and the main action visitors should take. List the required pages, languages, content already available and tools that the site must connect to. For a redesign, include the existing address and the pages or workflows you need to preserve.
Give the provider a budget range and a target date with its reason. Record unknowns such as whether you need independent content editing or a confirmed booking system. An initial estimate can identify those uncertainties; the scope should resolve them before they become delivery assumptions.
The project brief guide includes a small-business example you can adapt.
Use a comparison table
Add one column for each proposal. Write “unclear” where the document does not answer a point, then request clarification.
| Item | What to record |
|---|---|
| Pages and languages | Named pages, templates and translated versions |
| Content | Who writes, translates, supplies images and enters the final material |
| Features | Exact behaviour of forms, galleries, accounts, booking or payment |
| Design and feedback | Deliverables, review stages and included revision process |
| Existing website | Content migration, URL preservation, redirects and launch coordination |
| Testing | Devices, critical journeys, accessibility checks and acceptance process |
| Access and handover | Domain, hosting, source, editing interface and documentation |
| Commercial terms | Price basis, taxes, payment milestones, validity and change process |
| Ongoing costs | Hosting, domain, licences, maintenance and external subscriptions |
| After launch | Support scope, reporting channel, coverage and exclusions |
Compare the assumptions as carefully as the included features. “Contact form” could mean a simple message request or a multi-step application with attachments and an administration interface. Ask for the actual journey.
Real examples of different scopes
The LR Studios website presents a mobile-game catalogue and sends visitors to download platforms. That public presentation does not require the same scope as building the games or processing purchases on the website.
The MAHVU project includes a WordPress theme and a front-end publishing form designed for blind members. Publishing access and usability tests are material deliverables, not details captured by counting public pages.
The Sanegon case study covers intervention on an existing WordPress site, followed by a static rebuild with rewritten content and structure. A takeover requires understanding what exists before specifying what will replace it.
These are examples of delivered work, not public quotes or price benchmarks. They show why a meaningful proposal needs to describe responsibilities and functionality.
Clarify the price and change process
For a fixed scope, ask what is included in the stated price and how additional requests are estimated and approved. For time-based work, ask for the estimate, reporting arrangements and any agreed spending limit. Avoid assuming that a short total is a complete commitment when key inputs are missing.
Check payment milestones, applicable taxes and recurring charges in the actual commercial documents. Make sure those documents address delivery, acceptance, cancellation, rights and support. Resolve unclear terms before accepting them; this checklist is not a substitute for interpreting a specific agreement.
A booking screen, for example, may need an external subscription. Clarify who opens the account, who pays it and who configures confirmations and availability. The online booking guide helps distinguish an enquiry from a confirmed appointment.
Ask for observable acceptance criteria
Replace “fast and SEO-friendly” with concrete work to review: important pages return correctly, navigation and content remain accessible, metadata is consistent and key user tasks work on mobile. If an audit or performance target is included, specify its pages, method and conditions.
Search rankings and sales depend on more than the build. A technical acceptance criterion should not be confused with a promise of a particular Google position or a number of enquiries.
For a form, agree on a test submission and its destination. For a multilingual site, check that switching languages reaches the corresponding page. For an editing interface, ask someone who will use it to complete a real content update.
Check continuity and handover
Confirm who owns the domain and who can access hosting, source code, content and third-party accounts. Ask what can be exported and whether any licences or platform restrictions affect a future move.
Define maintenance separately: updates, backups, restoration checks, content changes and incident response may have different coverage. The maintenance checklist provides a practical way to review that scope.
Your final comparison should leave you able to explain what each proposal delivers, what you must provide and what remains outside the price. You can review my services or send a project outline to start that discussion with the same checklist.