What a useful website scope needs to settle before a quote means anything: pages, content, evidence, systems, responsibilities and the commercial job.

Quoting a website from a page count is like quoting a building from the number of rooms. It says nothing about what needs to happen inside them, what already exists or who is responsible for supplying the missing pieces.

A quote is only as useful as the scope behind it

Before we attach a number to a project, we need to understand the commercial job, the audiences, the pages, the content and the systems involved. Otherwise, the number is either padded for uncertainty or low enough to become a problem later. Padding is the more common failure, because it is the safer one to make quietly — nobody complains about a project that came in under a number that was never honest to begin with.

The scope turns those unknowns into decisions. It shows what is included, what is not, what we need from the client and which assumptions would change the price if they turn out to be wrong. A scope is not a defensive document. It is the thing that lets both sides agree, in writing, before either of them has spent a day on it.

What we check first

Four questions come up every time, and they come up in this order because each one narrows what the next one needs to answer.

1. What must the site change for the business? Not "what should the site have" — what number is supposed to move because this project happened. Enquiries, applications, a specific product's sales, time saved on a support line. A project without an answer to this is a design exercise with a deadline.
2. Which audiences and decisions does it need to support? A site selling to three distinct buyer types is not one site with three sections; it is three arguments that happen to share a navigation bar. Naming them early stops the homepage from trying to speak to all three at once and ending up specific to none.
3. Which content, proof and integrations already exist? Case studies, testimonials, product data, a CRM, a payment processor, a booking system. What exists gets audited, not assumed; what does not exist gets scheduled, not discovered in week six.
4. Who owns feedback, approvals and delivery on each side? One name per side, not a committee. A scope with two decision-makers on the client side who have not agreed with each other yet is a scope that will be renegotiated live, during the project, at the worst possible time to renegotiate it.

What a scope document contains

A scope we are willing to quote against names the pages, the argument each page makes, and the evidence that argument needs. It is usually two or three sides of A4. If it cannot be written that briefly, the project is not understood well enough to price.

Pages and their jobs

Every page gets one sentence describing what a visitor should be able to do or believe by the end of it. Pages that cannot be described this way are usually pages nobody needed. This step alone tends to cut a proposed sitemap by a quarter — not because the pages were wrong, but because nobody had asked what job each one was doing before that moment.

Evidence

Claims need proof: case studies, numbers, named clients, screenshots of real work. Gathering that is often the longest part of a project, and it is the part most likely to be discovered late if nobody scoped it. A page that promises "see our results" and then has no results to show is worse than a page that never made the promise — it is a broken argument sitting where a working one should be, and it gets found by exactly the visitor who was closest to convinced.

Systems and integrations

What the site has to talk to changes the estimate more than what it has to display. A contact form is an afternoon. A contact form that has to create a record in a CRM, notify a Slack channel and trigger a follow-up email sequence is a small integration project wearing a form's clothes. We list every system the new site touches — analytics, payments, booking, inventory, email — before we price anything, because the third-party API with sparse documentation is never the thing anyone remembers to mention up front.

Content

Who is writing the copy, and against what deadline. A scope that says "client to provide copy" without a date is a scope that will slip, because writing copy competes with every other thing the client's team is doing that week, and it is always the easiest deadline to miss quietly. We name the pages that need copy, who is drafting each one, and the date we need it by to hold the rest of the schedule — and where the client would rather we write it, that gets priced and scheduled as its own piece of work, not folded silently into "design."

Responsibilities and timeline

Who supplies which piece, and by when. Copy, images, legal review, product data, brand assets — each gets an owner and a date, on both sides. A scope that only lists what the agency will do is half a scope; the half that determines whether the timeline holds is usually the client's half.

What happens without one

Discovering mid-build that the site needs eleven case studies nobody has written costs a month, and it arrives at exactly the point where everyone has run out of patience for anything that is not visible progress. Discovering that "the site" was supposed to include a client portal, and one side thought that was obvious while the other thought it was a phase two, costs the relationship, not just the timeline. None of these are unusual. They are what happens, by default, when a project starts from a page count instead of a scope — and they are close to impossible to fix gracefully once the build is underway, because by then every conversation about scope reads as a conversation about blame.

Scoping properly costs a week. The failures above cost a month and a conversation nobody wanted to have, and they arrive precisely when the goodwill that would make that conversation easy has already been spent on something else. The pattern is always the same shape, whatever the specific gap turns out to be: something that felt too obvious to write down turns out to have been understood differently by the two people who needed to agree on it, and the disagreement only surfaces once it is expensive to resolve.

What legitimately changes the price after a scope exists

A scope is not a promise that the number never moves — it is a promise that it only moves for reasons both sides can name. Legitimate reasons: a page turns out to need content that does not exist yet and someone has to write it; an integration's real API is more limited than its marketing page suggested; the client adds a genuinely new requirement mid-project. Illegitimate reasons: the estimate was optimistic to win the work, or "tightening the design" turns into redesigning three pages that were never in scope. The difference between the two is whether the change traces back to a fact nobody had when the scope was written, or to a decision someone is making now and hoping not to have to justify.

Who actually writes it

The client supplies the inputs — the commercial goal, the audiences, whatever proof and content already exists, the internal decision-maker. The agency turns that into the document: the pages, the argument each one makes, the systems it touches, the order everything has to happen in. Writing a scope is not something a client is expected to arrive with. Answering the four questions above, honestly and specifically, is.

That division of labour matters more than it looks. A client who tries to write the scope themselves usually produces a page count with opinions about colour attached, because that is what "a website" looks like from the outside. An agency that writes a scope without real answers to the four questions produces a document that reads well and prices wrong, because it is filling gaps with assumptions instead of asking. The document only works when each side supplies the part only they can see.

In short

Decide what the site has to prove. Write down how each page proves it, what it needs to touch, and who is responsible for supplying the missing pieces. Then, and only then, design something around that argument — because the design will be faster, cheaper and better when there is nothing left to argue about.