Unlimited revisions in web design: warning sign or real protection?

Search "web design revisions" and nearly everything you find was written for designers, not for you. It's agencies telling other agencies how to survive unlimited-revision clauses, cap scope creep, and get paid for extra rounds. That's a strange thing to notice as a buyer, because the same clause that gives designers a headache is the one being sold to you as a perk.

Here's the contrarian read: an open-ended revision promise is not a benefit you're being given, it's a symptom of a process that doesn't have a defined finish line. If a vendor can't tell you how many rounds are included, they haven't decided when the project ends. That's not generosity. It's an unscoped commitment with your name on the invoice.

What "unlimited revisions" actually means in a contract

The phrase hides a conflation that works in the vendor's favor: it blurs a revision round with a single edit request. Prominent Web Design defines a round as "a full set of feedback that your web design team addresses before the next," not a running tally of every message you send. DeepThree Design draws the same line, describing a revision as "a change requested after a draft has been delivered," which still implies a batch, not a chat thread.

That distinction matters because "unlimited" can mean three different things depending on which side of it you're standing on:

• —Unlimited rounds, no time limit and no definition of what triggers one.
• —Unlimited minor tweaks within a single round, but the round count itself is capped.
• —Unlimited rounds, but only inside a fixed window of time.

Vendors rarely say which one they mean. That ambiguity is the point: it lets "unlimited" sound the same in a sales page whether it protects you or exposes you.

Why agencies advertise it, and what it costs the project

An open-ended revision policy costs the agency time and costs you a delivery date. Every source written for the designer's side of this exists because of that cost. It describes the same failure mode from the inside: feedback that never converges, scope that keeps expanding one small request at a time, and a launch date that keeps slipping because there's no mechanism that says the project is done.

Flip that around and it's a buyer's warning sign, not a designer's inconvenience. If a policy has no defined end condition, nothing forces a decision. You can keep sending changes indefinitely, which feels like leverage until you notice the site still isn't live. Scope creep and indefinite timelines aren't a cost the agency absorbs alone. They're a cost you pay in the form of a website that stays unfinished.

How many web design revisions is actually reasonable?

Skip "it depends." Two sources that specialize in this question converge on a number: Prominent Web Design states "most web design teams offer two to three rounds for most simple projects," and DeepThree Design reports "most professional website projects include two to three structured revision rounds." Two independent write-ups landing on the same range is a real benchmark, not a guess.

The number should flex with the project, and DeepThree breaks that down by type: small business sites usually need two rounds, realtor and IDX sites run two to three, and e-commerce builds often need three or more given the added product and checkout screens to review. A brand-new build from a blank brief should sit at the low end of that range if the brief was clear going in. A full redesign of an existing site, where stakeholders are reacting to something they already have opinions about, tends toward the higher end.

Here is what neither write-up does with the number, and it is the part that decides whether it protects you. A round count is a proxy. The thing you actually want is an end condition, and the count only stands in for one when the vendor also defines what a round is and says what happens when the count runs out. Strip either of those away and "two rounds included" is every bit as unbounded as "unlimited," because nothing in it closes the project.

Our own structure is the worked example of the alternative, and it is fair to say plainly that Press is one of the vendors this framing audits. We publish no round limit at all. What bounds the work is a clock: ten days from the day you decide to keep the site, unlimited rounds inside it, and a round count that never enters the contract. The cited two-to-three range is still useful, but as an estimate of what fits inside a bounded period, not as the rule that ends the project.

So the benchmark to apply is not a number on its own. It is a number attached to a stated end condition, and the two halves are worth grading separately. Two included rounds, a written definition of a round, and a published price for the third is a tighter deal than unlimited rounds with none of the three.

One thing worth flagging while you grade it: Prominent Web Design recommends two to three rounds as best practice, then states its own policy is that it "generally does not put limitations on the number of revision rounds." The advice and the vendor's own incentive don't always point the same direction, and a written recommendation is not the same thing as a contract term.

How long do web design revisions take?

This is the gap nobody fills in. Kosmo's revision policy guide advises setting a specific round count and defining what counts as a revision, and Prominent Web Design and DeepThree both note that extra rounds beyond the included amount typically get billed. None of the three guides consulted here publishes a per-round turnaround time or a total number of days revisions typically add to a project. We are not going to fill that hole with an invented industry average.

What we can put on the record is our own time budget and the arithmetic that follows from it. Press builds the first draft in five working days, before any revision clock starts. Revisions then run for ten calendar days from the day you decide to keep the site, with no cap on rounds inside the window. Set the two-to-three round range against ten days and the per-round budget falls out: three rounds leaves a little over three days each, two rounds leaves five. That budget covers both sides of the exchange, our turnaround on the edits and your own time to look at the result and decide what to say next. Two rounds is comfortable at that pace. Four is a sprint.

Read that as a sizing check rather than a promise, and note that it is arithmetic on our published figures, not a market norm. The check is the useful part, because it transfers: take the round count or the window a vendor quotes, divide it into the calendar time before the launch date they also quoted, and see whether the answer leaves room for your own review. A policy offering three rounds against a two-week launch is quoting a schedule that only works if you reply the same day, every time. That is worth knowing before you sign it rather than in week two. For the fuller picture of how a project timeline breaks down start to finish, see how long a website takes to build.

What a structured revision policy looks like instead

The alternative to an open-ended promise is a policy that's round-based, defines what a round is, and ties revisions to a specific review stage rather than an indefinite post-launch window. Bounding revisions this way protects both the timeline and the quality of the work: reviewers give consolidated feedback once per stage instead of trickling in requests, and the project has a visible point at which it's actually finished.

This is where it's worth naming our own model directly, since it's a working example of the time-boxed version rather than the unbounded one: Press includes unlimited revision rounds, but only for ten days from the date you decide to keep the site, as described on how it works, from brief to finished website. That's the middle option from the list above: not a capped round count, and not an open-ended promise with no end condition either. The window is what does the work a round limit would otherwise do. Unlimited stops being a scope risk once there's a clock attached to it, and it's fair to count Press among the vendors this whole framing is auditing.

How to vet a revision policy before you sign

Ask these four questions before you sign, and listen for whether the answer is specific or evasive. The pattern is the same each time: a specific answer names a mechanism, and a disqualifying one defers the decision to a point where you have less leverage than you do now.

This checklist runs deeper than any single FAQ line, and it's worth pairing with the full question-and-answer set in questions to ask a web designer, which covers the rest of the hiring conversation beyond revisions specifically.

That last question is doing more work than it looks like. A revision round can only refine something both sides already agreed on, so a policy of any shape is being asked to absorb whatever the brief left undecided. Grade the answer accordingly: a vendor who can list what they need from you before the clock starts has thought about where rounds get spent, and one who can't is leaving that discovery inside the revision period you are about to buy. For the fuller version of that groundwork, our guide to what belongs in a website brief covers it.

Who pays for the extra rounds?

Every source consulted here confirms that additional rounds get billed once the included amount runs out, and none of them publishes what that costs. Prominent Web Design notes only that "some web design agencies may charge for extra revision rounds," and DeepThree describes the same practice, "billed hourly or per round," again without a figure. The models worth asking about directly are a flat per-round fee, hourly billing, or a capped add-on priced up front.

Those three are not equally checkable, which is the part that matters when you are comparing quotes:

Press uses the third, and publishes the figure: past the free ten-day window, one paid "Extra revision" add-on buys one further round, priced $49 / RM99 / S$49 by market. We are stating it here because none of the three guides consulted above states one, and because an audit that finds a gap should say where its own author sits in it. The point isn't that a capped add-on is the only correct structure. It's that whichever model a vendor uses, it should be defined in the contract before work starts, not negotiated once you're partway through revisions and already invested in the outcome.

Questions