Website quote: common mistakes when requesting and reviewing one

You receive two proposals for a website, and the amounts are very different. One appears to include everything; the other details many tasks you had not considered. Before choosing the lowest-priced or most extensive option, it is worth resolving a more important question: are you comparing the same project?

A website quote helps turn a business need into an understandable scope: what the website is intended to achieve, what will be delivered, what depends on you and what is excluded. By the end of this guide, you will be able to identify the gaps that make proposals difficult to compare and prepare a clearer request.

What a website quote is meant to achieve

The goal is not to set a figure without context. It is to agree on the problem the website should help solve and the work that forms part of the first release.

To avoid confusion, separate three levels:

• Objective: what the business or the person visiting the website should be able to do. For example, explain a service more clearly and make it easier to request information.
• Scope: pages, content, forms, languages, migration, integrations, testing, training or other elements required to achieve that objective.
• Solution: the way it will be built, such as a structure based on existing components or a development with specific features.

Two quotes may use different technologies and address the same objective. They may also appear similar while concealing very different scopes. That is why comparison starts with scope, not the total price.

Common mistakes when requesting or reviewing a website quote

1. Asking for a “complete website” without describing what it needs to achieve

Symptom: your request uses terms such as “modern website”, “professional” or “complete”, but does not indicate what action the visitor should take or what business need it should address.

Cause: the starting point is a visual idea or a technical label before the problem has been defined. A website intended to present services, receive enquiries, manage bookings or sell products does not necessarily require the same approach.

Consequence: each provider interprets the brief in their own way. The resulting proposals may include different work even when they use similar language, making price comparisons less useful.

Correction: write a specific sentence about the expected outcome. Then identify who will visit the website and the main action they should be able to complete. If there are several objectives, rank them by priority.

2. Mistaking a list of pages for the actual scope

Symptom: the quote mentions Home, Services, About Us and Contact, but does not explain what content each page will contain or which sections will have their own behaviour.

Cause: it is assumed that one page represents the same unit of work as another. However, an informational page, a catalogue, a page with filters or a private area involve different requirements.

Consequence: questions arise during the project about copy, visual assets, reusable blocks, forms or ongoing management. If they are not clarified, these decisions may alter the planned work.

Correction: for each page or page type, specify its purpose, available content, required elements and approval owner. You do not need to design every detail before requesting a quote, but you should distinguish what is simple from what requires rules, data or interaction.

3. Assuming that content is included

Symptom: there is talk of “refreshing the website”, but it is not known who will write the copy, provide images, review service descriptions or upload the final material.

Cause: content is treated as material that will appear at the end, when it affects structure, reviews and launch.

Consequence: the website may be held up while waiting for information, or published with placeholder copy that does not represent the business well. It also becomes difficult to know whether a proposal includes copywriting, uploading, editing or only the structure where the content will go.

Correction: prepare a simple inventory: what content exists, what needs to be created, what needs updating and who validates it. If you are migrating information from another website, indicate the approximate volume and whether current URLs need to be retained or redirected.

4. Mentioning features without defining the user flow

Symptom: the brief includes “a form”, “bookings”, “a client area” or “a connection to a tool”, but does not describe what happens before and after the action.

Cause: the feature is named, but its rules are not defined. A form needs fields, a recipient, confirmation and error handling. An integration requires knowing what data is sent, when it is sent and what happens if the external service does not respond.

Consequence: the same label can conceal very different levels of complexity. It also becomes difficult to verify whether the delivery meets your expectations.

Correction: describe each feature using four questions: who uses it, what action they take, what outcome they expect and which exceptions are relevant. For example, in a hypothetical case, it is not enough to request “a contact form”; it is useful to indicate what data it requests, which email address or system the enquiry should reach and what confirmation the person completing it will see.

5. Not separating essentials from desirable additions

Symptom: all ideas are presented as necessary to publish the first version: new sections, languages, integrations, pending content and future features.

Cause: no decision has been made about which elements support the initial objective and which can wait. This happens easily when the project brings together needs from several departments or people.

Consequence: the website quote becomes harder to understand and the project is exposed to ongoing changes. Postponing something may seem like an arbitrary cut when it is actually a prioritisation decision.

Correction: classify each item as essential, desirable, future or out of scope. Ask for the proposal to reflect this distinction. This will allow you to assess a viable first release without losing the improvements you want to address later.

6. Comparing proposals only by the final price

Symptom: you choose a proposal because its total is lower or reject another because it appears more expensive, without reviewing line items, assumptions and exclusions.

Cause: price is easier to compare than scope. But an isolated figure does not explain whether it includes design, content, migration, testing, tool configuration, training, maintenance or third-party dependencies.

Consequence: you may accept a proposal that does not cover a need relevant to your case, or pay for elements that do not contribute to the objective of the first version.

Correction: compare each proposal against the same list of needs. Identify what is included, what is excluded, what remains to be confirmed and what recurring costs or services may exist in addition to the initial build. If two proposals do not address the same scope, they are not comparable yet.

7. Leaving exclusions and maintenance in the background

Symptom: the proposal details the initial delivery but does not clarify who will manage updates, access, incidents, backups, licences or subsequent changes.

Cause: publication is treated as the end of the project, when the website will continue to require owners, accounts and maintenance decisions.

Consequence: tasks without an owner or recurring costs that had not been considered may arise. Dependency also increases if it is not clear who controls access, the domain, hosting or connected services.

Correction: ask for a clear separation between the initial build, recurring services and future development. Confirm which accounts exist, who will own them, who will be able to access them and what support is expected after publication.

8. Accepting timelines without reviewing dependencies and approvals

Symptom: there is a desired date, but pending content, access to tools, internal reviews and the person responsible for making decisions have not been identified.

Cause: the schedule is framed as a fixed date rather than linked to specific deliverables and dependencies.

Consequence: delays accumulate and affect the project, making it difficult to know which decision or material is needed to continue.

Correction: identify which date has a real reason behind it and what must happen beforehand to meet it. Define who reviews each deliverable, how much time they need to do so and what information must be available before each phase begins.

How to prevent these mistakes before requesting proposals

You do not need to resolve the entire technical solution on your own. You do need to make the decisions that change the scope visible. A short, well-organised brief is usually more useful than a generic request with many visual references.

Include, at a minimum:

1. The website objective and the main action expected from the visitor.
2. The audience profiles it must address.
3. The planned pages, sections or content types.
4. The status of copy, images, documents and catalogue, where applicable.
5. The required features and the flow for each one.
6. The tools that need to connect to the website and the available access.
7. What must be included in the first version and what can be postponed.
8. The real constraints: date, review owners, languages, migration or internal requirements.
9. What you expect to manage once the website is published.

Questions you cannot resolve do not invalidate the request. Mark them as open. It is preferable for uncertainty to remain visible than for it to become a different assumption in every proposal.

Checklist for reviewing a website quote

Before accepting or comparing a proposal, check these points:

• The objective is written in terms of a specific action or need.
• The pages and content are described in enough detail to understand their function.
• It identifies which content already exists, what is missing and who will approve it.
• Each form, private area, booking or integration has a defined flow.
• Essential items are separated from future improvements.
• Assumptions, included tasks and relevant exclusions are stated.
• Migration of content, data or URLs is explicitly confirmed where applicable.
• The initial build, recurring services and later changes are differentiated.
• It is clear who controls accounts, access and external tools.
• There is a way to verify each relevant deliverable before accepting it.
• The schedule accounts for pending content, reviews and decisions.

Next step: turn an idea into a reviewable scope

A good website quote does not eliminate every future decision, but it makes clear which ones have been made, which are assumptions and which must be validated before moving forward. That clarity enables you to compare proposals effectively and reduce misunderstandings about what you will receive.

If you have a project idea but the scope still combines pages, content, features or integrations, you can tell AVSISTEC about your web development project to review what information is worth defining before requesting a proposal.