How to scope a website project so it doesn't creep
How to scope a website project so it doesn't creep: name the content types, the sections and the edits up front, and price everything outside that list.
Scope creep rarely arrives as a big request. It arrives as "while you're in there", as a second kind of testimonial, as a team page that now needs filtering by office. Each one is small enough to feel petty to refuse, and by the end of the project you've built a different site from the one you quoted.
Most of that isn't the client's fault. It's the scope document's. Here's how to scope a website project so the edges are visible to both sides before anyone starts.
Why scope creeps
The usual scope lists pages. A home page, an about page, a services page, a contact page, a blog. It reads clearly and it describes almost nothing.
"A services page" could be one page of text, or twelve services each with their own page, pricing table, case studies and enquiry form. "A blog" could be posts with a title and a body, or posts with authors, categories, related posts and a newsletter sign-up. The client has a picture in their head. You have a different one. The page list lets both pictures fit, so neither of you notices the difference until the build makes it concrete.
Pages are the output of a website. They're the wrong unit for describing the work.
Scope the things, not the pages
Describe the site as what it contains and how those things are built. Four lists cover almost every brochure site.
Content types. The kinds of thing the site holds: service, case study, team member, blog post, location, job. For each, its fields, and whether it gets its own page. "Team member: name, role, photo, short bio, office. Listed on the About page. No individual pages." That last sentence alone prevents a common argument.
The section library. The reusable sections pages are composed from: hero, text with image, feature grid, testimonial, logo strip, call to action, form. Name each one and say what it contains. If a section isn't on the list, it isn't in the build.
What the client can edit. Which fields are theirs to change, and which are fixed. Can they add a section to a page? Reorder them? Create a new page? Write it down, because "can I change that myself" is the question you'll hear most in month two.
Integrations. Every third-party service the site touches: booking, newsletter, maps, analytics, payments. For each, what you're doing (embedding their widget, or building against their API) and what you're not.
That's the content model, written for a client. If you haven't thought about a site this way before, what is a content model covers the building blocks.
Make it one page
Put those four lists on a single page as an appendix to the proposal. Not a forty-page specification nobody reads; one page the client can hold up against the finished site. When a request arrives, you both look at the appendix. It's either there or it isn't.
The out-of-scope list matters as much
Write a second list, just as specific: what this project doesn't include. Individual pages for team members. Filtering on the case studies. A members area. Multiple languages. Migration of more than a set number of posts. Copywriting. Photography.
Clients don't read an absence as a decision. They read it as something you'll do if they ask nicely. An explicit "not included" turns a later request into a new line item instead of an argument about what you meant. It also tends to surface the client's real priorities during the sale, which is the cheapest time to hear them.
Change requests: new kind versus new content
Once the site is live, almost every request falls into one of two groups, and the scope should say how each is handled.
A new kind of thing is a change to the build. A new section type, a new content type, a new field, a new integration. It's quoted work, because someone has to design it, model it and build it.
New content is the client's job. Another service, another team member, another post, another page made from existing sections. It costs nothing because nothing about the site has changed.
The line between those two is the line between structure and content, and holding it is most of what keeps a site profitable after launch. We make the longer argument in content control, not design control. How to decline the custom requests gracefully is in saying no to a custom build.
Migration and content entry
The forgotten line item. Who types the content in, and from where?
If there's an existing site, say what comes across: how many pages, which content types, whether images are re-used or replaced. If the client is writing new copy, say when it's due and what happens to the timeline if it isn't. If you're entering content, say how much and charge for it. Content entry is real work and it's almost always underestimated by both sides.
Where a platform helps
If your platform builds the client's editor from a content model, the scope appendix stops being a description of the site and becomes the site's actual definition. In Contentive the content types, fields and reusable sections you list are what you build first, and the client's editor shows exactly those, so "can I add a pricing table to this page" is answered by whether the pricing section exists, not by a conversation. Structure and content are separate permissions, so the line between a change request and an edit is enforced rather than remembered.
What this costs
Scoping this way takes longer up front. A page list takes ten minutes; four lists take an afternoon and a conversation with the client that some of them would rather skip. It can also make the quote look bigger, because you've written down work that a page list hides. That's an honest price, but it can lose you a pitch against someone quoting the vague version. Decide whether you want that project.
A template you can lift
Content types: name, fields, whether each gets its own page, how it's listed.
Sections: name and contents of each reusable section; nothing outside this list.
Editing: what the client can add, change, reorder and create; what's fixed.
Integrations: each service, and what you're building against it.
Content entry: who supplies content, by when, how much you'll enter.
Not included: at least five specific items.
Change requests: new kinds of thing are quoted; new content is the client's.
If you find yourself filling this in for every project, you're close to a productised service, which is what running a productised website service is about.