← All essays
Mozi2026-09-27By Anderson#mozi#client revisions#definition of done#freelance clients#project scope#small business

Client Keeps Asking for One More Change: When Is It Done?

凡足以奉給民用，諸加費不加民利則止。 — Whatever suffices to supply what people use; added expense that adds no benefit, stop there. (《墨子·節用中》, my translation)

Short answer: the work is done when it meets a standard the two of you agreed on before it started — not when the client runs out of ideas. Revision caps meter what changes cost. They never say what finished looks like. That's why nothing ever gets finished.

A freelancer put the problem better than any consultant has. Posting to r/Freelancers, they asked how you actually handle a client who keeps asking for "one more small change" — and pre-empted the standard answer: "Not the obvious answer ('put it in the contract') I mean in the actual moment."

Key Takeaways

  • A revision cap is a budget, not a finish line.
  • Herbert Simon (1956): search stops at a fixed aspiration level, never at "best."
  • Scrum's Definition of Done is a state, not a count of rounds.
  • Mozi's rule: keep what adds function, drop what doesn't, 則止 — stop there.
  • Write the standard before the work, not after round three.

Why don't the change requests ever stop on their own?

Because nobody set a level at which they were supposed to stop. In Psychological Review in 1956, Herbert Simon argued that real decision-makers don't optimise; his phrase was that organisms "adapt well enough to 'satisfice'; they do not, in general, 'optimize.'" His model creature works because it has, in his words, "a definite, fixed aspiration level."

Your client has no such level. They aren't sabotaging you. They're searching — and search without a threshold doesn't terminate, it just gets interrupted by a deadline or by embarrassment. Every look at the work generates one more idea that is, taken alone, genuinely an improvement.

Citation capsule: Herbert Simon's 1956 paper "Rational Choice and the Structure of the Environment" (Psychological Review 63:2, 129–138) replaced maximising with satisficing: a bounded agent stops when an alternative clears a fixed aspiration level. Client revision loops run forever for the reverse reason — no aspiration level was ever set, so nothing ever clears it.

There's a cost to that, and it isn't only yours. Schwartz and colleagues, in JPSP in 2002, found that people who maximise rather than satisfice report lower satisfaction with their decisions and more regret. Your client isn't enjoying round seven either. Nobody told them they were allowed to be done.

The best-voted reply on that r/Freelancers thread lands in the same place from pure experience: "A lot of these just never get declared finished by anyone."

Why doesn't "three rounds of revisions" fix it?

Because a count caps your exposure without describing the destination. You can burn all three rounds and still be nowhere. A designer on r/graphic_design (6 points, 53 comments) described exactly that: three rounds in, the client had changed direction entirely and they were "basically starting from scratch."

Look at what the four common fixes actually do:

Stopping ruleWhat it controlsWhat it declares finishedFails when
"Three rounds of revisions"Your exposureNothingThe brief itself moves
Hourly billingYour payNothingClient has budget and patience
Change order per requestPrice of each askNothingThe asks are all in-scope tweaks
Written completion standardThe finish lineThe deliverableYou skip writing it

Only the last row answers the question. The other three are meters. A meter can run a very long time.

What did Mozi actually say about when to stop?

He gave the stopping rule its shortest form: 則止 — stop there. The Mohists were the ancient world's efficiency engineers, and the Moderation in Use chapter of the Mozi is a list of standards, each ending on that same two-character clause.

The general rule, from 《節用中》: 「凡足以奉給民用，諸加費不加民利則止。」 Whatever suffices to supply what people actually use; added expense that adds no benefit — stop there. He then applies it, tediously and on purpose, to food, clothing, weapons, boats, houses. Each one states the function, then stops.

The test is sharper in 《節用上》, where it runs in both directions: 「凡爲衣裳之道，冬加溫、夏加凊者……不加者，去之。」 In making clothes: what adds warmth in winter or coolness in summer — keep. What adds neither, remove.

That's not frugality advice. It's a completion criterion. The garment is done when it clears the function, and every further change has to earn its place by adding function, not by being an improvement in someone's taste.

Citation capsule: The Mozi's 《節用中》 fixes completion by function: 「凡足以奉給民用，諸加費不加民利則止」 — whatever suffices for actual use; added expense yielding no added benefit, stop there. 《節用上》 states the test in both directions: what adds function, keep; 「不加者，去之」 — what adds none, remove. A deliverable, not a budget, is what gets declared finished.

Isn't this just a definition of done?

Yes, and that's the point — software solved this and freelancing didn't. The 2020 Scrum Guide, by Ken Schwaber and Jeff Sutherland, defines it in one line: "The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product."

Read it next to Mozi and the shape is identical. A state, described in advance, external to anybody's mood on the day. Not three rounds. Not "until the client's happy."

<!-- [UNIQUE INSIGHT] -->

Here's what I haven't seen anyone point out: the Mohists were already doing this as a general method. The Stanford Encyclopedia's entry on Mohism describes their fa — their standards — as working by "citing a fa, comparing something to it, and then judging whether the two are similar," and calls that "the Mohists' basic conception of practical reasoning." The Mozi opens 《法儀》 with the flat claim 「天下從事者，不可以無法儀。無法儀而其事能成者，無有。」 Nobody undertaking anything can do without a standard; nothing has ever been accomplished without one. That's a definition of done, written about twenty-three centuries before the Scrum Guide, and stated as a universal condition on finishing work at all.

Citation capsule: The 2020 Scrum Guide defines Done as "a formal description of the state of the Increment when it meets the quality measures required for the product" — a state, fixed in advance, not a count of review rounds. The Mozi states the same condition in 《法儀》: nothing has ever been accomplished without a standard to measure it against.

How do you write a completion standard before you start?

Write down what the deliverable is for, in one sentence, then list the three or four things it must do. Not adjectives. Functions. "Converts visitors on mobile" is a function. "Feels premium" is a mood, and moods can't be met.

Then agree the review shape in the same breath. One agency owner on r/agency (54 points, 78 comments) replaced revision rounds with a ten-business-day feedback window, unlimited inside it, day-rate outside it. In that same thread, another commenter named the real gap: most teams never define "what 'ready for feedback' actually means," so "every review becomes a discovery session."

Three things to put in writing, before any work starts:

  1. The function list. What this must do, in the client's words, checkable by both of you.
  2. The review window. When feedback opens, when it closes, what happens after.
  3. The word "final." Someone has to say it out loud. Usually that someone is you.

A warning from a manufacturer, because this isn't only a creative-work problem: a poster on r/textiles had sign-off in writing and it still didn't hold — "the client approved these things in writing. email confirmation, everything. and now they're acting like that approval didn't mean anything." Approval of a round isn't approval against a standard. Only the second one closes.

Is this the same problem as scope creep?

No, and treating them as one problem is why the usual advice bounces. Scope creep adds work that was never in the deal. Revision loops repeat work that always was. Different failure, different repair.

Scope creepEndless revisions
What arrivesA new thingThe same thing, again
What's missingA boundaryA finish line
The fixPrice the askDefine done, in advance
Contract statusBeing exceededBeing satisfied, indefinitely

Citation capsule: Scope creep and endless revisions are distinct failures. Creep adds work outside the agreement and is fixed by pricing each new ask. Revision loops repeat work already inside it, and pricing does nothing, because in-scope tweaks are already paid for. Only a completion standard agreed in advance closes the second one.

The move that works on creep — pricing the ask instead of refusing it — does very little here, because in-scope tweaks are already paid for. It's also why charging a flat fee bleeds on exactly this failure and hourly doesn't: without a completion standard, a flat fee is an unbounded promise. And it's upstream of the ugly one, since a deliverable nobody declared finished is how you end up chasing an invoice.

Where does the Mozi analogy stop?

At taste, and at the cost of being wrong. Mozi's austerity was ferocious and unlovely — he wanted music abolished as waste, and his function test would flatten a lot of work that's good precisely because it exceeds its brief. Borrow the stopping rule; don't borrow the aesthetics.

The rule also cuts back at you. If the client's tenth request genuinely adds function, it isn't creep and it isn't indecision — it's a gap you missed, and 「加者」 says keep it. A completion standard that only ever protects the supplier isn't a standard. It's a shield.

Mozi is the calculating one among the ten sages, which is why this framing fits him and not the others. If you want to think through your own standard out loud, ask Mozi directly. Related, from the same sage: when one client is most of your income and Mozi and Bentham on impartial concern, or his full profile. For the number itself rather than the finish line, see raising prices without losing customers.

FAQ

How do I stop a client from asking for endless revisions?

Define done before you start: state what the deliverable must do in three or four checkable functions, set a fixed feedback window, and say the word "final" when you send the last round. Revision caps only limit your cost — they never declare the work complete, which is the thing the client is waiting for.

Is three rounds of revisions a good limit?

It's a useful budget and a poor finish line. A designer on r/graphic_design burned three rounds and ended up restarting from scratch because the brief itself had moved. Pair any round cap with a written completion standard, or the cap just meters a process with no defined end.

What's the difference between scope creep and endless revisions?

Scope creep adds work that was never in the agreement; revision loops repeat work that always was. Creep is fixed by pricing each new ask. Revisions are fixed by defining completion in advance. Applying the creep remedy to a revision loop fails, because in-scope tweaks are already paid for.

What is Mozi's "moderation in use"?

Chapters 20–21 of the Mozi set standards for food, clothing, housing, weapons and boats, each ending in 則止 — stop there. The rule: whatever suffices for actual use is enough, and added expense that adds no benefit should be dropped. It reads as frugality, but it functions as a completion criterion.

Does a contract prevent this?

Not by itself. A poster on r/textiles had written, emailed sign-off on each stage and the client reopened settled decisions anyway. A contract governs what you owe; a completion standard governs when you've delivered it. Most freelance contracts specify the first and say nothing about the second.

Sources and a note on the text

On the text and the translation. Chinese source text for 《墨子·節用上》, 《墨子·節用中》 and 《墨子·法儀》 is taken from Chinese Wikisource and quoted character for character. All English renderings are my own, literal, from that Chinese; W. P. Mei's The Ethical and Political Works of Motse (1929) and Ian Johnston's The Mozi: A Complete Translation (Columbia University Press, 2010) are the standard scholarly English translations. One honest wrinkle: in 《節用上》 the positive half of the clothing test is textually corrupt in the received edition (the graphs 「𦬒䱉」), while the negative half — 「不加者，去之」 — is clear; the parallel passages in 《節用中》, quoted above, carry the same rule intact, so the reading does not rest on the damaged characters. Chapter attribution follows the received text; the composition history of the Mozi is layered and disputed.

Client Keeps Asking for One More Change: When Is It Done? · Hundred Masters