How to scope a website project so the quote survives the build
A scope is a list of what you'll deliver and, just as important, what you won't. It goes wrong when a requirement sounds small in the meeting and turns out to need a feature the tool doesn't have. The fix is to check every requirement against what the builder does today before you put a price on it, and write the answer into the scope.
Start from outcomes, then list features
Begin with what the site has to achieve in the client's terms: more booked consultations, fewer phone calls asking about opening hours, a place to send people from a trade show. Then turn each outcome into concrete pieces: pages, forms, bookings, payments, content the client will edit. Outcomes keep the scope honest; features make it checkable.
Check each requirement against what the builder does
This is the step most scopes skip. For an Anticode build, the questions below cover what usually comes up. Anything marked as another tool needs a line in the scope saying who provides it.
| Requirement | On an Anticode site | If it's needed anyway |
|---|---|---|
| Several pages | Separate pages such as Services, About, Pricing, FAQ, Book and Contact | Fine as is |
| Contact form | Fixed fields: name, email, message; emailed and sent on through connectors | Other fields need a custom form with a site function (up to 30 plain-text fields) or an app build |
| Booking | A booking calendar: six fixed times a day, Mondays skipped, one booking per slot, up to 120 days ahead; you confirm each booking yourself | Your own hours or slot lengths, deposits, calendar sync or staff rotas need a booking service |
| Taking payment | Buy buttons open a payment link from Stripe, PayPal, Gumroad, Lemon Squeezy, Shopify or Whop | A cart, stock or shipping needs a store platform |
| Content the client edits | CMS collections edited in the dashboard | Comments, RSS or scheduled posts need a blog platform |
| Logins for customers | Not on published sites | The Next.js export has real accounts, for a developer to extend |
| Several languages | Not supported; pages are in English | Another platform |
| Moving an old site | Rebuild from the old site's link; no import | Allow time for content |
A quick way to test an uncertain requirement is to describe the site to the Architect before quoting. It asks up to three questions where the answer changes the build and shows a plan with the kind, sections and features. If a feature you expected isn't in the plan, you've found a scope question early.
Write the scope document
- Purpose. One or two sentences on what the site must achieve.
- Pages and sections, listed by name.
- Forms and where submissions go, naming the inbox, channel or sheet.
- Integrations, each with who owns the account: the client's payment provider, their CRM, their email tool.
- Content responsibilities. Who writes the copy, who supplies photos, and by when.
- Exclusions, stated plainly: "no online shop, no customer logins, no translation".
- Revisions, with the number of rounds and how extra rounds are charged.
- Launch, including the domain and who controls its DNS.
Pricing extra revisions
Revision rounds are where scope quietly expands. Define a round (one consolidated set of comments from the named approver, applied together) and include a fixed number, often two. Price additional rounds as a flat fee or by the hour, and say so in the scope. Anticode shows a quote before each build and only counts successful builds against the plan's allowance, so you can see what large reworks cost you on the tool side as well as in time. See website revision rounds.
What goes wrong
- "Can it also do..."
- A mid-project request that isn't in the scope. Answer with a short change note and a price, not a yes in passing.
- Assumed integrations
- The client assumed the booking calendar would sync with their diary. It doesn't, and the scope should have said so.
- Content arrives late
- The build waits. Tie content deadlines to the launch date in the scope.
How you know the scope worked
The project ends at roughly the price you quoted, every change request was either in scope or priced, and nobody was surprised at launch by something the site doesn't do. Keep each project's scope; the next one starts from it.
Limits
Anticode can help you check requirements and build what's in scope. The scope document, the contract and the change notes are yours. Where a requirement needs code, a Next.js export gives a developer a standard project to extend, but that work and its cost belong in the scope too. The proposal workflow covers presenting all of this to the client.
Questions people ask
How to scope a website project when the client isn't sure what they want?
Scope a smaller first phase around one outcome, such as enquiries, with a fixed price. Put the uncertain features in a named second phase to be scoped later.
Should exclusions really go in the scope?
Yes. Listing what's not included, such as a shop, logins or translation, prevents most launch-week arguments.
What if a requirement needs a feature Anticode doesn't have?
Name the other tool in the scope and who owns its account, or plan a Next.js export for a developer. Don't promise it as part of the build.