How we scope a web project

Most web projects that go wrong went wrong before anyone wrote code. Two parties agreed to different things, discovered it three months in, and spent the rest of the budget arguing about whose fault it was. Scoping is the work of making sure we are agreeing to the same thing. Here is how we do it, and what you can prepare to make it faster.

Discovery: understand before estimating

We do not estimate from a first email. We estimate after discovery, which for a marketing site takes a few days and for a product takes one to two weeks. Discovery is paid on larger projects, because it is real work and because it produces a document you can take to another agency if you decide we are not the right fit.

What we ask

The business goal. Why this, why now, and what changes if it works. “We need a new website” is a symptom; “our sales team cannot send prospects to the site without apologising” is a goal.
The users. Who they are, what they are trying to do, and what they do today instead.
The content. What exists, who owns it, what is missing, and who will write the rest.
The systems. CRM, payments, authentication, analytics, and the spreadsheet everything actually runs on. Every integration is a place where an estimate can be wrong.
The constraints. Budget range, dates that matter and why, brand guidelines, legal or compliance requirements, hosting preferences.
The decision makers. Who approves each stage and how quickly they can review.

Who we talk to

The sponsor, the person who will run the site day to day, and someone who talks to customers, usually in sales or support. The third conversation is the one that changes the scope most often, because that person knows which questions the current site fails to answer.

What we look at

Existing analytics and Search Console data if they exist, the current codebase and infrastructure if there is one, and a handful of competitor sites to understand what the audience already expects.

What comes out

A short discovery note: what we heard, what we think the real problem is, and the questions still open. It is a page or two, not a deck. You read it, correct it, and only then do we write a scope.

The scope document

The scope is the contract in plain language. It has six parts, and the second is the most valuable.

What is in. A numbered list of pages, features or screens, each with a sentence on what finished looks like. “Blog with categories, an RSS feed and an author page” rather than “blog”.
What is out. Explicitly. The things you mentioned that we are not doing in this phase, and the things people usually assume are included but are not: content writing, photography, data migration, a second language, ongoing hosting.
Assumptions. Content is delivered by a named date. Design feedback arrives within five working days. Third-party APIs behave as their documentation says. The site is deployed to your own cloud or Cloudflare account. When an assumption fails, the scope changes, and saying so up front avoids the argument later.
Non-functional requirements. Performance budgets (we default to Core Web Vitals in the good range on mobile), accessibility (WCAG 2.2 AA), browser support, security headers, redirects from every old URL, and analytics and consent requirements.
Milestones. One- to two-week blocks, each ending in working software on a staging URL. Each milestone has a price or an estimate range.
Acceptance. How a milestone is reviewed, who signs it off, and the difference between a bug (we fix it) and a change (it goes on the change list with a cost).

How we estimate

We estimate in ranges, not single numbers, because a single number hides where the uncertainty is. For most web projects the uncertainty lives in three places: integrations, content, and data that nobody has looked at closely.

The estimate is built bottom-up. Each scope item is sized by the person who will build it, and we add a contingency that is stated separately and explained. If a part of the project is genuinely unknown, we propose a time-boxed spike first: two days to prove that the payment provider supports refunds the way the finance team needs, and then an estimate for the rest.

Where the scope is clear we quote a fixed price per milestone. Where the work is exploratory we work on time and materials with a cap, and we tell you which model we are proposing and why. Both are fine; mixing them without saying so is not.

What drives cost most, in roughly this order: the number of distinct templates or screens, the number and maturity of integrations, content migration, custom design versus a design system, the number of review rounds, and compliance requirements. Fewer distinct things is the cheapest lever there is.

Changes during the project are normal. Each one is a short written note: what changes, what it does to the timeline and the cost, and a yes or no from you. Nothing is built from a chat message.

What a good brief contains

You do not need a formal document, but the more of this you can send before the first call, the shorter discovery is.

The business goal in one or two sentences, and how you will know it worked.
Who the users are and the two or three things they most need to do.
Must-haves and nice-to-haves, labelled as such.
The systems the site must connect to, with links to their documentation.
The state of the content: what exists, who owns it, what needs writing.
Constraints: budget range, deadlines that matter and the reason they matter, brand guidelines, legal requirements.
Examples of sites you like and dislike, and why. The why is the useful part.
Who decides, and how quickly they can turn around a review.
What happens after launch: who maintains the site, and where it should be hosted.

A brief that says “we do not know” in several places is a good brief; that is what discovery is for. A brief that says “make it modern and clean” tells us nothing and costs you a week.

After the scope is signed

Kick-off sets up the repository in your account, the staging environment, access to the tools, a shared channel and the milestone calendar. The first milestone is always the riskiest part of the project, not the easiest: the hardest integration or the core flow. If something is going to go wrong, we want to know in week two.

Every week you get a short written status: done, next, blocked, decisions needed. Every milestone ends with something you can click.

A note on fixed dates

If a date cannot move, whether it is a launch event, a regulatory deadline or a campaign already booked, tell us first. We scope backwards from the date and cut scope to fit it. We do not cut testing, accessibility or performance, because those are the things that make the launch worth having.

If you are preparing a brief now, send it over. We will come back with questions before we come back with a number.