How to Say No to "Just One More Revision" Without Sounding Difficult¶

"Just one more small change" is one of the most reliable phrases in client work, and it's almost never actually one small change - it's a doorway to another round of feedback that reopens things the last round supposedly settled. Saying yes every time feels like the path of least conflict, but it doesn't actually protect the relationship. It just quietly moves the cost of an unscoped project from an explicit conversation now to an unsustainable workload later, at which point the eventual pushback lands much harder than it would have the first time.

The Discomfort of Saying No Now Is Smaller Than It Feels¶

Most designers overestimate how badly a client will react to a reasonable boundary and underestimate how badly resentment builds up after absorbing round six of "just one more thing" for free. A clear, calm boundary stated early in a drift almost always lands better than the same boundary stated after weeks of quietly absorbing extra rounds, because the first version reads as a normal professional standard and the second version reads as a sudden, frustrated reaction to something the client didn't realize had become a pattern.

Reference the Agreement, Not Your Personal Limit¶

The easiest way to hold a line without it feeling personal is pointing back to what was actually agreed at the start of the project - "the scope included two rounds of revisions, and we're now on round four" is a statement of fact, not an opinion about whether the client's request is reasonable. This reframes the conversation from "I don't want to do this" (which invites negotiation about your willingness) to "this is outside what we scoped" (which invites a conversation about scope instead) - a much easier conversation to have without it feeling adversarial.

Offer the Yes, Just With the Real Cost Attached¶

Saying no to "for free" doesn't have to mean saying no to the request itself. "I can absolutely make that change - it's outside the rounds we scoped, so it'll be billed at [rate] for an additional round" gives the client a real choice instead of a closed door, and most clients will either agree to the cost or realize on their own that the change isn't as necessary as it felt in the moment. This works because it removes you from being the obstacle - the client is now weighing the request against its actual cost, not against your willingness to help.

Set the Expectation Before It's Tested, Not After¶

The revision boundary is far easier to hold if it was stated clearly at the very start of the project, in writing, before any pressure exists to bend it - "this project includes two rounds of feedback; additional rounds are billed at [rate]" in a proposal or contract does most of the work before a single revision request ever arrives. A boundary introduced for the first time in the moment it's being tested will always feel more confrontational than one that was simply restated from something already agreed.

FAQ¶

What if the client pushes back and says this wasn't made clear enough at the start?
That's a fair thing to hear and worth taking seriously for future projects - but if the scope was documented anywhere, even briefly, pointing back to it directly and calmly ("this is outlined in the proposal we agreed to") resolves the disagreement about facts before it becomes a disagreement about fairness.

Does holding this line risk losing the client entirely?
Rarely, if it's communicated calmly and paired with a real option to proceed at a fair added cost - clients who leave over a reasonable, clearly-stated scope boundary were usually going to be a difficult, unprofitable relationship regardless of how this particular moment was handled.

Is it different for a long-term retainer client versus a one-off project?
Somewhat - a retainer relationship has more room for occasional flexibility since the value evens out over time, but even there, a pattern of unscoped extra rounds is worth naming explicitly rather than absorbing indefinitely, just with a softer tone than a one-off project might need.