What Should Be Included in a Fixed-Price Website Scope?
A fixed-price website scope should define pages, copy, design rounds, CMS fields, integrations, SEO, analytics, QA, launch, and what is excluded.
A fixed price is only as honest as the scope behind it. When a website project blows past budget, it's almost never because the team was slow. It's because "a few landing pages" quietly became twelve, "simple forms" became Salesforce routing, and nobody wrote down where the line was. A good scope document isn't bureaucracy. It's the thing that lets a fixed price actually stay fixed.
We run fixed-scope website sprints, so we've learned exactly which omissions cause budget fights. Here's what a scope should spell out, and what it should explicitly exclude.
A fixed price needs a fixed list
The whole premise of fixed pricing is that both sides agree on the deliverables. The moment scope is implied rather than listed, you've reintroduced the open-ended risk fixed pricing was supposed to remove. Everything below exists to make the list explicit enough that "done" is unambiguous.
State the outcome first
Begin with the business goal and the primary conversion action. "A site that books qualified demos" frames every later decision differently than "a site that looks modern." When scope starts from outcome, it's easy to spot deliverables that don't serve it, and to defend the ones that do. This is the anchor the rest of the document hangs on.
List the deliverables exactly
Name the exact pages, templates, CMS fields, and integrations. Not "core pages": homepage, two service pages, about, contact, legal. Not "a CMS": which content types, which fields, which roles. Not "integrations": which CRM, which analytics, which form routing. Ambiguity here is where budgets go to die; specificity is the cure. If it's not listed, assume it's not included, on purpose.
Define the review process
Set the approval points and the number of revision rounds. Two structured rounds on defined templates is a sane default, not unlimited "make it pop" feedback that never converges. State clearly that a third round becomes a change request with a timeline impact. Revision ambiguity is the second most common budget killer after page count.
Make launch deliverables explicit
Launch is where scope quietly goes missing. Include analytics setup, SEO, forms, QA, and deployment responsibilities as named line items. If SEO and analytics are assumed rather than written, they get skipped, and you launch a site that can't be measured or found. Spell out metadata, sitemap, Search Console setup, GA4 events, and form testing.
Write the exclusions down
A scope without exclusions isn't finished. State plainly what requires a change request: net-new copy research, custom app integrations, multilingual beyond agreed locales, ongoing content entry, paid media, and anything labeled "phase two" without a date. Naming exclusions isn't defensive. It protects the price for both sides and prevents the awkward mid-project renegotiation.
| Scope section | Must specify |
|---|---|
| Outcome | Business goal + conversion action |
| Deliverables | Exact pages, templates, CMS fields, integrations |
| Reviews | Approval points, number of rounds |
| Launch | Analytics, SEO, forms, QA, deployment |
| Exclusions | What triggers a change request |
Why fixed-price projects overrun
It's almost always loosely defined scope, not slow execution. "A few landing pages" becomes twelve; a CMS becomes custom ecommerce; "simple forms" becomes complex routing. Fixed price works precisely when deliverables are listed rather than implied. The document is the budget control.
What to do next
Draft your scope from outcome down to exclusions this week, before you collect quotes. It makes proposals comparable. If you want a scope and a fixed price from a team that ships in a week, Metamatter writes the deliverables explicitly and builds to them, no junior handoff.
Turn the scope into a shared checklist
A scope document only protects you if both sides actually use it. Turn the deliverable list into a shared checklist that doubles as your acceptance criteria: each page, template, CMS field, integration, and launch task with a clear done state. Review it at kickoff so there are no surprises, and revisit it at each milestone so "is this in scope?" has a written answer instead of an argument. When a new request appears mid-project (and it will), point to the checklist and price it as a change request rather than absorbing it silently. This isn't rigidity; it's what lets a fixed price stay fixed and a relationship stay friendly. The clearest scopes we write are the ones nobody ends up needing to dispute. And the discipline pays off twice: a tight scope at the start makes the eventual handoff cleaner, because everyone already agrees on what was built, what was excluded, and who owns the site the day after launch.
FAQ
Why do fixed-price website projects go over budget?
Scope wasn't explicit: "a few landing pages" became twelve, the CMS became custom ecommerce, "simple forms" became Salesforce routing. Fixed price works when deliverables are listed, not implied.
How many design revision rounds should scope include?
Two structured rounds on defined templates, not unlimited "make it pop" feedback. A third round should become a change request with timeline impact.
Should SEO and analytics be line items or assumed?
Line items. Assumed means skipped. Scope should name metadata, sitemap, Search Console setup, GA4 events, and form testing, or you'll launch without them.
What belongs in exclusions?
Net-new copy research, custom app integrations, multilingual beyond agreed locales, ongoing content entry, paid media, and anything labeled "phase two" without a date.
