On this page
Scope creep rarely arrives as a big new request. Nobody emails to say "we'd also like a mobile app". It arrives in the feedback round, one small change at a time, until the project you priced is not the project you're doing.
The feedback round is where it starts, so that's where it's easiest to stop – kindly, and without damaging the relationship.
The innocent "small change"#
Here's how it usually goes. You send the homepage for review. The client comments: "Love it. Could we add a section for our partners here?" It's a reasonable request. It's also not in the brief.
Saying yes feels easy. It's one section. The client is happy, you want them to stay happy, and arguing about one section feels petty. So you add it.
Then the next round has two more small changes. Then a new page "while you're in there". None of them is big enough to make a fuss about, and together they add a week to a project priced for none of it.
The problem isn't the changes. Clients are allowed to want things. The problem is that nobody noticed they were changes, so nobody decided whether to pay for them.
Separate feedback from new requests#
Feedback is a response to the work you were asked to do: "the headline is too long", "this blue is too dark", "the button should say Book a call". It's part of the job, and the review rounds in your proposal exist for it.
A new request is something that wasn't in the brief: a new section, a new page, a new feature. It may be a great idea. It's still new.
The single most useful habit is sorting comments into those two groups as they arrive, out loud. When you reply to a review, answer feedback as feedback and name new requests as new requests:
- "Headline shortened, blue darkened – both in v3."
- "The partners section is a new addition to the brief. Happy to add it – I'll send a quick estimate today."
The client doesn't have to agree to pay. They just need to know it's a decision. Most of the time they'll say "yes, add it" or "let's leave it for phase two", and both are fine outcomes.
Version numbers are a contract#
When every version has a number and every approval is tied to one, the project has a memory. "You approved v4 of the homepage on the 12th" is a fact, not an argument.
This matters most later. Three weeks after sign-off, the client asks why the partners section isn't there. Without a record, it's your word against their memory. With one, it's a short, friendly conversation: v4 was approved without it, and here's the estimate to add it now.
Version numbers also help the client. When they say "the one before", everyone knows which one that is.
A script for saying "that's a change request" kindly#
The hard part isn't knowing something is out of scope. It's saying so without sounding like you're counting minutes. Here's a version that has worked for a lot of agencies we talk to:
Great idea – this would make the page stronger. It's outside what we scoped, so I'll send a short estimate for adding it. If you'd rather keep this phase on budget, we can note it for the next one.
It does three things. It agrees with the client, so they don't feel turned down. It names the change clearly, without blame. And it offers a choice, so the client stays in control of their budget.
Say it early, and say it every time. The first change request is the easiest one to name. If you let three through for free, the fourth is much harder to charge for.
Tracking change requests without a spreadsheet#
Change requests need a home, or they get lost in email. The simplest version is a list in the project with four columns: what was asked, when, the estimate, and the decision.
A spreadsheet works, but it lives away from the work, so it gets updated on Fridays if at all. It's better to track change requests where the feedback happens. In Ferrybox, any comment can be marked as a change request; it stays attached to the version and the place on the design where it was made, and it shows in the project's change list with its status.
Whatever you use, review the list with the client at each milestone. It takes five minutes, and it turns scope from an awkward subject into a routine one.
Make room for good ideas#
Not every addition is a problem. Sometimes the client's new idea is better than the brief, and saying no to it would make the work worse. The goal isn't to block changes; it's to make sure they're chosen, priced and planned.
Some agencies build a small buffer into every proposal – a few hours explicitly reserved for "improvements we agree on during the project". It gives you room to say yes to a good idea without a new estimate, and it makes the limit visible: when the buffer is used, the next addition is a change request.
Scope creep isn't a client problem or an agency problem. It's what happens when changes aren't named. Name them in the feedback round, and most of it never happens.
