How to scope a project so a vendor can't scope-creep you

Scope creep isn’t usually a vendor acting in bad faith. It’s usually a scope document that never defined its own edges clearly enough to know when something falls outside it. Fix the document, most of the creep goes away on its own.

What most scopes get wrong

They describe what should be built, in detail. They rarely describe what should NOT be built, and that missing half is exactly where creep lives. Without an explicit boundary, every reasonable-sounding addition looks like it was always implied.

The fix: write the “out of scope” section first

Before listing deliverables, list exclusions. Explicitly. “This project does not include mobile app support.” “This does not include data migration from the old system.” Anything not written down as excluded will eventually get argued as included, by either side, often in good faith.

Define “done,” not just “delivered”

A scope that says “build a booking page” is incomplete. A scope that says “build a booking page that handles X, Y, Z scenarios, and is considered done when it passes these three specific test cases” gives both sides a concrete finish line instead of a moving target for what “finished” means.

Price changes into the document itself

Not every addition is scope creep, sometimes priorities genuinely change mid-project. The fix isn’t preventing all change, it’s pricing it in advance: a stated rate or process for anything added after signing, agreed before it’s needed, not negotiated under pressure once it is.

The part that actually protects you

Not a longer contract. A more specific one, especially about what’s excluded and what “done” concretely means. Vagueness is what creep exploits, on both sides of the table, whether or not either side intends it that way.