What a website quote should include: a checklist for comparing proposals

Receiving a website quote is a useful step, but the final amount alone does not tell you whether two proposals are comparable. What matters is understanding the problem each one addresses, what the work includes, what the business needs to contribute, and which conditions are required to publish.

This guide is for reviewing a proposal after you receive it. If you are about to request quotes, first read what to prepare before requesting a website quote. That guide is for the earlier stage: organising the objective, materials, and priorities before starting conversations.

1. The website’s purpose and scope

A proposal should make clear what it is intended to solve. It is not enough to say “build a website”; it should explain whether it is a landing page for an offer, a corporate website, an update to an existing presence, or a first version to validate a need.

Review which sections, pages, or journeys it covers. For example, a services overview, contact page, frequently asked questions, catalogue, form, or a specific integration. If the document uses broad terms, ask for them to be translated into concrete deliverables or decisions.

When the objective is still undefined, scope is difficult to evaluate. Our guide on landing pages and corporate websites can help identify which kind of presence fits your business at this moment.

2. Content, materials, and responsibilities

A website needs content to work: copy, photos, services, contact information, a logo, brand messages, and, in some cases, additional information for forms or integrations. The quote should state which materials are considered and who is responsible for preparing, organising, or uploading them.

Look for answers to these questions:

• Does the business supply copy and images, or does the proposal include support to organise them?
• How many content sections are included?
• Who reviews and approves information before publishing?
• What happens if materials arrive late or change substantially?

These definitions are not intended to place all the work on the business. They help clarify the collaboration required and what can affect the timeline.

3. Timeline, reviews, and dependencies

A useful timeline is more than a delivery date. It should account for project stages, review points, and the conditions required to move forward. Some tasks depend on content, access, approvals, a domain, external platforms, or internal decisions within the business.

Check whether the proposal explains:

• The main stages and their order.
• When the business needs to respond or approve.
• How many reviews are expected and which deliverables they cover.
• How changes that arise after a stage is approved are handled.
• Which external dependencies could move the publication date.

A schedule cannot eliminate all uncertainty, but it can make visible the points where both sides need to coordinate.

4. Investment, payments, and taxes to clarify

A quote should make it possible to understand how the investment is structured: what belongs to the service, what belongs to external platforms, and when each payment is made. If milestones or payment stages are included, they should relate to understandable deliverables or moments in the project.

Tax matters, receipts, currency, payment method, or specific terms can vary according to the client and provider. Rather than assuming them, ask for them to be clarified directly in the proposal or the relevant conversation. This guide does not replace accounting, tax, or legal advice.

To understand why two proposals can differ, read which factors change the investment in a website. The comparison is more useful when read together with the scope.

5. Exclusions and ongoing costs

A good proposal also explains what is not included. This can cover additional content, new sections, integrations not described, changes after an approval, audiovisual production, licences, or services managed by third parties.

Also ask about costs that may continue after publishing, such as a domain, hosting, email, form tools, analytics, licences, payment gateways, or maintenance. This does not mean all of them apply to your project. It means you need to know which ones exist, who contracts them, and how they are managed.

6. Publishing, accounts, and access

Before accepting, clarify how the website will go live and who will have access to the necessary services. Depending on the project, this can include a domain, hosting, a code repository, analytics accounts, forms, email, or third-party platforms.

A clear proposal should distinguish between creating or configuring an account and owning it. Ask which access the business will retain, what information is handed over at the end, and what is needed to make changes later. This avoids relying on assumptions after the website is live.

7. Support after launch

Publishing does not always mark the end of every need. You may need to resolve agreed adjustments, check connected tools, or define a maintenance arrangement. The quote should explain whether there is a support period, which types of requests it covers, and which work is priced separately.

Avoid interpreting “support” as unlimited availability. What matters is knowing its scope, channel, duration, and how future requests are handled.

Signals that you should ask for more clarity before deciding

Not every proposal needs to be long, but it is worth asking for context when:

• The website’s objective is missing or does not match the initial conversation.
• Functions are mentioned without explaining how they work or what they depend on.
• It is not clear which content the business needs to provide.
• There is a timeline without stages, reviews, or defined responsibilities.
• Provider services are mixed with the costs of external platforms.
• Nothing explains what happens with access, publishing, or support after launch.
• The scope seems to change without a way to agree on adjustments.

Asking for these clarifications is not about distrusting the team. It is a way to protect the project and decide with enough information. If you are also comparing studios, this guide to choosing a studio to build your website can help.

A checklist for comparing proposals

Before deciding, review each quote with this list:

• The objective and type of website are described.
• The pages, sections, content, and functions are understandable.
• The business’s and team’s responsibilities are clear.
• The timeline includes reviews, approvals, and dependencies.
• The investment, payments, and points that need clarification are identified.
• Exclusions and possible ongoing costs are visible.
• Publishing, access, and account ownership have been discussed.
• Post-launch support has a defined scope.
• I know which questions I need to resolve before accepting.

A quote does not need to anticipate every detail of a project. It should give you enough of a foundation to know what you are comparing and which conversation still needs to happen.

If you want to review the scope of a website before making a decision, message us on WhatsApp and tell us which proposal or need you are evaluating.