There was a project a couple of years ago where the design was approved, then approved again, then reopened. Not because anything was wrong with it, but because a new person joined the client's team and wanted to see options. We showed options. Someone else preferred the earlier direction. We went back. Then the first person returned with notes on the version we had already reverted.
None of it was malicious. Every individual request was small and reasonable. Together they added about three weeks to a four-week project, and we absorbed every hour of it, because nothing in the contract said we should not.
That was the project that taught us how to prevent scope creep, and the lesson was not about managing clients better. It was about what the contract does not say.
What causes scope creep?
Scope creep is caused by contracts that define the deliverable but not the number of times you will produce it. When only the output is specified, the work is effectively infinite: "a homepage design" is not a scope, and what the client reasonably hears is "a homepage design, revised until you are happy," because nothing in the document contradicts that reading. The common explanations — the client changed their mind, the brief was vague, expectations were not set clearly — describe symptoms rather than the mechanism. A project with unlimited revisions built into its agreement will slide regardless of how well anyone communicates, and a project with a stated revision limit usually will not. This is why scope creep is best treated as a contract problem rather than a client-management problem.
Clients are not gaming you when they ask for a fourth round of changes. They are operating inside the boundaries you gave them, and you did not give them one. A person asking for revisions has no way of knowing that round three was free and round four costs money, unless the contract said so before round one.
This is also why "just push back more firmly" does not work as a strategy. Pushing back on a request that your own contract permits puts you in the position of renegotiating mid-project, from a weaker position, against someone who is not doing anything wrong. You lose the argument or you win it and damage the relationship. Neither is good.
What contract clause prevents scope creep?
The clause that prevents scope creep has two parts: a fixed number of revision rounds per deliverable, and a stated hourly rate for anything beyond that. Both parts are necessary. The round limit alone just creates an argument once it is reached, because the client still needs the change and you still have no agreed way to price it. The rate alone does nothing, because without a stated limit there is no point at which it starts applying. Together they turn a potential conflict into an ordinary commercial decision: the work is outside the included rounds, here is the estimate, shall we proceed. It is two sentences in the agreement, it takes ten minutes to add, and it has held up across every project since we started using it:
A fixed number of revision rounds per deliverable. We use two for most work, three for anything where the client's internal approval chain is long. A round is defined as one consolidated set of feedback, not one message — otherwise five people emailing separately counts as five rounds and everyone feels cheated.
A stated hourly rate for anything beyond that. Not a penalty, not a threat. Just a number: additional revisions are billed at X per hour, estimated and approved before the work starts.
The second sentence is the one that does the work, and it took us a while to understand why. It is not there to make money on extra rounds. It is there so that the conversation about a fourth round is a normal commercial conversation with a known price, instead of a negotiation about whether the request is fair.
What changed after we implemented it
The thing we expected was fewer revision requests. That did happen, but it was not the main effect.
The main effect was that feedback got better. When a client knows they have two consolidated rounds, they collect input from their whole team before sending it, instead of forwarding reactions as they arrive. We started receiving one organized document instead of eleven messages over five days, which meant we could actually address everything at once. Fewer rounds, but also better rounds.
The second thing was that the awkward conversation disappeared. When someone asks for a third round now, we do not have to decide whether to say something. We say: that is outside the included rounds, it looks like about four hours, here is the cost, shall we proceed. Roughly half the time they proceed. The other half they realize the change was not that important. Both outcomes are fine, and neither one involves anybody feeling taken advantage of.
The third thing, and the one we did not anticipate, was that it improved how we scoped work in the first place. Once a revision round has a stated cost, you get much more careful about making sure round one is aimed correctly. We ask better questions before starting, because a vague brief is now expensive for us in a way it was not before.
How many revision rounds should a contract include?
A contract should include two revision rounds for most work and three when the client has a long internal approval chain, with additional rounds billed hourly. The exact number matters far less than having one at all. Two rounds is not a magic figure — it is simply enough for one substantive revision and one round of polish, which covers the large majority of projects that were scoped correctly in the first place. What makes the clause work is not its strictness but its existence: a boundary written down before the project starts is a shared expectation, while the same boundary introduced halfway through is a complaint. Pick a number you can live with, define what counts as a round, and state what happens after. Put a number in your contract. That is the whole recommendation.
It is one of the few things that made running client work alongside our own products sustainable rather than exhausting.
It does not have to be two rounds, and the hourly rate does not have to be high. What matters is that a boundary exists in writing before the work starts, because a boundary you introduce halfway through a project is not a boundary, it is a complaint.
The clause is not there to protect you from bad clients. Bad clients will ignore it and you will have other problems. It is there to protect good projects with good clients from the slow, well-meaning accumulation of small requests that nobody meant to be a problem, and that nobody had a reason to stop.