How Many Revisions to Include in an AI Project (Before You Start Charging for More)

Two rounds of revisions, included in the price, defined as fixing anything that doesn't match what was scoped. Round one happens after the first delivery. Round two happens after I've made those changes. After that, anything further is a new, priced request, not a continuation of the same invoice.

That's not a rule I invented to protect my time in the abstract, it's the fix for a specific failure mode Claude Code makes worse, not better. A build that used to take a week now takes an afternoon, which means the temptation to treat every follow-up message as a free, instant re-generation is stronger than it ever was with slower tools. Two structured rounds keeps that speed from quietly becoming an open-ended queue.

Unlimited revisions sounds like a strong offer on a proposal, and it costs you almost nothing to type. What it actually does is remove the client's only incentive to give you clear, complete feedback in one pass. If round three is free and round four is free too, there's no reason not to send a one-line note today and another one tomorrow, each one restarting your context and stretching a project that should have closed weeks ago.

This is the line that actually matters, more than the number itself. A revision fixes something that doesn't match what you agreed to build. A new request is a change of mind, a new feature, or a different direction than what was scoped. Confusing the two is where free revisions quietly turn into free scope expansion.

Say this distinction out loud the first time a request lands in the second column, don't just quietly absorb it. Most clients aren't trying to sneak in free work, they genuinely don't know where the line is until you draw it. Naming it once, calmly, usually settles the question for the rest of the project.

A round isn't a round if it arrives as five separate messages over three days. When I deliver a build, I ask for every piece of feedback in one message before I touch anything again, that's what makes a round countable and closeable. Feedback that trickles in one line at a time doesn't just cost more of your time, it makes it genuinely harder to tell when a round has actually ended.

Set a short window for that one bundled pass, three to five business days is typical, and say plainly that revisions submitted after the window starts the next round instead. That keeps a client's slow reply from stretching your own timeline indefinitely, and it gives both sides a clear moment where the project is either done or explicitly moving to another round.

This is what we call the Change Line inside the club: the exact sentence in your contract that states the revision count and turns any new request into a priced change instead of an argument. See [what to put in an AI project contract](/blog/what-to-put-in-an-ai-project-contract) for where it sits alongside the rest of the six-clause baseline, and [how to handle scope creep on client projects](/blog/how-to-handle-scope-creep-on-client-projects) for what to do once a request clearly crosses the line.

A verbal mention on the kickoff call doesn't hold up three weeks later when a client genuinely doesn't remember agreeing to a cap. Put the number in the proposal and in the contract, in the same plain language you'd use talking to them directly, not buried in legal boilerplate they skimmed past.

State it once, plainly, as a normal part of how every project runs, not as a condition you're specially imposing on this client. I write some version of: this includes two rounds of revisions on the agreed scope, submitted as one bundled pass within five business days of delivery. Anything beyond that, or anything outside the original scope, is billed at my standard rate. No apology, no hedge.