Round one goes fine. Round two adds “just a couple more things.” By round three nobody remembers whether the homepage hero was actually approved or just not-yet-complained-about, and the contract that promised “revisions included” never said how many. That gap — no number, no definition of what one revision covers — is where an unpaid fourth, fifth, and sixth round comes from.
The fix starts before the project does, not mid-review. Here’s how many rounds to actually put in writing, what should count as one, and what to do when a client — or you — inevitably wants more.
How many rounds of revisions should a website redesign include?
Two to three rounds is the standard for a small-to-mid-size website, with more complex builds needing more. Prominent Web Design puts it plainly: “Most web design teams offer two to three rounds for most simple projects. More complex and larger websites, for say e-commerce platforms, can require more.” ReviewMyContract’s scope-of-work clause guide recommends getting more granular than “the whole project” — it suggests “website design: 2 rounds per page template for small to mid-sized projects,” so a five-template site (home, about, services, blog, contact) gets ten total revision passes distributed across the pieces, not two passes across the entire site at once.
Elementor’s website development contract guide draws the outer edge: if a designer can’t land on a satisfactory result “in 5 to 7 rounds, you’re either doing something wrong, or you should have seen the red flags before you even started the project.” Two to three per template is the working number; five to seven total is the ceiling before something structural is wrong with the brief, not the feedback.
Does the number change for a full redesign vs. a smaller update?
Yes — scope size, not project type, is what should set the count. A five-page redesign and a five-page rebuild from scratch carry roughly the same revision math, because both involve the same number of templates going through the same review passes. What actually moves the number is complexity within each template: an e-commerce product page with variant selectors, inventory states, and a checkout handoff needs more passes than a static about page, which is exactly the distinction Prominent Web Design’s guidance draws between “simple projects” and larger builds like e-commerce platforms. A single-page landing site redesign might reasonably sit at the low end of two rounds total; a ten-template redesign with a checkout flow should be budgeted per template, not treated as one lump project with a flat number bolted on regardless of size.
What actually counts as “one round” of revisions?
One round is every piece of feedback on a deliverable submitted together, reviewed once, and responded to once — not each individual comment. HubSpot’s web design contract guide recommends specifying revisions per phase rather than per project, with a template that reads: “[NUMBER] rounds of revisions for wireframes. [NUMBER] rounds of revisions for visual designs. [NUMBER] rounds of revisions for development.” Splitting it this way stops a client from treating “two rounds” as two individual complaints they can spend across six weeks — a round is a batch, not a coupon.
That structure also settles the ambiguity that causes most disputes: whether a stray message two days after “final approval” is round two or a favor. If a round is defined as a phase-bound batch, the answer is automatic — new comments after sign-off on a phase start the next round, whether anyone calls it that out loud or not. Simpl_Markup’s guide to closing out a review without an endless email thread covers the sign-off side of the same problem: once a round is marked approved, reopening it should be a deliberate decision, not something that happens by accident because nobody defined where the round ended.
What’s the difference between a revision and a change order?
A revision fixes something to match what was already agreed; a change order changes what was agreed in the first place. ReviewMyContract’s guide states it as a one-sentence test: “A revision is defined as a modification to bring a deliverable into conformance with the specifications in this Agreement” — while a request that “change[s] the specifications, add[s] new elements, or alter[s] the approach described in this Agreement is a change order,” subject to additional fees. Swapping a headline’s wording to match an already-approved copy deck is a revision. Asking for a whole new homepage section that was never in the brief is a change order, even if it arrives in the same message as three legitimate revisions.
Most rounds don’t run out because of revisions. They run out because change orders get waved through as if they were revisions, with nobody stopping to ask which one just happened. Simpl_Markup’s post on stopping scope creep from turning one revision round into five covers the same split from inside an already-open round — this post is the upstream version: decide the definition before round one starts, so there’s a test to apply when round three tries to sneak a new ask in.
Why does “unlimited revisions” sound generous but usually backfire?
Unlimited revisions removes the one signal that tells a client their feedback is done, so review rounds expand to fill however much time is available. Simpfinity’s analysis of unlimited design revisions is blunt about the cost: when revisions “just keep coming, they’re a strain on your design team,” capable of blowing past the deadline, running the project over budget, and souring “relationships between creatives and clients” — the opposite of what an unlimited-sounding offer is supposed to buy. The same piece notes that agencies offering unlimited revisions are often doing it to compensate for thin margins rather than as a premium perk.
The wider project-management data backs the same pattern outside web design specifically. PMI’s 2018 Pulse of the Profession, cited by Project Management Academy, found that 52% of all projects experience scope creep — and that number is worse, not better, without an explicit scope-management process in place. A revision round with no ceiling is a scope-management process with the ceiling deliberately removed.
How do you write the revision limit into the contract without sounding stingy?
State the number up front as a shared planning tool, not a punishment — clients respond by sending tighter feedback, not by feeling rationed. Moxie’s freelancer guide to avoiding scope creep makes the behavioral case directly: “When a client knows they only have two rounds of included edits, you’ll get much more detailed and comprehensive feedback.” Illustrator Alvalyn Lundgren, quoted in the same piece, describes handling anything past the agreed scope the same way every time: “I communicate the details of the additions and the additions’ fees and time in a written change order. I do nothing until the change order is approved.”
HubSpot’s contract guide backs the same framing from the founder-facing side — clients who know the round count “think through their changes more carefully instead of sending tiny tweaks one at a time.” Practically, that means writing a single sentence into the kickoff doc or the contract itself: “This project includes [N] rounds of revisions per [phase/template]. Requests beyond that are handled as a change order, quoted and approved separately.” No hedging, no “we’ll be flexible about it” — the number is what makes flexibility possible later, not what removes it.
What happens once a client — or you — wants more rounds than the contract allows?
A change order, not a negotiation over whether the ask was fair. Elementor’s contract guide recommends including “a clause that outlines how you will handle scope extensions” specifically so nobody has to improvise the conversation mid-project — the alternative, per the same guide, is “death by 1000 emails,” where every small ask gets litigated individually because there’s no pre-agreed process for the ones that don’t fit. ReviewMyContract recommends the same three-part structure regardless of project size: a revision count per deliverable, a written definition separating revisions from change orders, and an excess-revision fee billed apart from the base project price.
This is where a structured review process earns its keep over a Slack thread of screenshots: the round boundary only holds if everyone can actually see where it is. Simpl_Markup tracks every comment’s status — open, fixed, approved — pinned to the exact element it’s about, so “is this round still open” is a visible fact instead of a memory exercise nobody agrees on. That’s a meaningfully different shape than reviewing through screenshots dropped into Slack, where a new ask and an already-resolved one scroll past looking identical. It also means the revision-round conversation happens with async feedback pinned in context, not reconstructed from a week-old thread when someone asks “wait, was that in scope?”
Put the number in writing before round one starts
Two to three rounds per page template, a one-sentence definition of what counts as a revision versus a change order, and a stated process for anything past the limit — that’s the whole contract clause, and it fits in a paragraph. The number matters less than having one. A client with a defined round count sends tighter feedback because they know it counts; a developer with a defined round count can say yes to “one more thing” without wondering whether they just gave away a week of unpaid work. Decide the number before the kickoff call, not during round four.