Web Project Revisions — How Many Is Reasonable and How to Structure Them
Revision policy is one of the most frequently contentious aspects of web development projects. Here is how I structure revisions after 150+ projects, and what I have learned about what is fair for both developer and client.
What "Revisions" Actually Means
A critical distinction that most project briefs miss: revisions to implement the agreed brief correctly versus revisions to change what was agreed. The first category is the developer's responsibility — if the mockup was validated and the code does not match it, that is a bug fix, not a revision. The second category is legitimate change management, but it should be scoped and potentially priced. Conflating the two is the primary source of revision disputes.
A Practical Structure That Works
My standard contract includes: 2 rounds of design revisions before development begins (on mockups/wireframes), and 1 round of content and functional revisions after the development build is delivered on a staging environment. Changes requested after final delivery on the live site are billed at the agreed daily rate. This structure gives clients genuine flexibility while protecting against infinite iteration loops that make projects unprofitable.
The Validation Document Prevents 80% of Disputes
Before writing a single line of code, I require a signed validation document for the design mockups. This document states explicitly: "The client confirms that this design is approved for development. Structural layout changes after this validation will be treated as additional scope." This single document resolves most revision disputes before they happen — clients who have signed off cannot reasonably request fundamental redesigns as "revisions."
Managing Revision Requests Professionally
When a client requests something outside the agreed scope, the professional response is not refusal — it is acknowledgment and re-scoping. "This change is outside our original scope — I can implement it for X MAD with a delivery in X days" is a straightforward business conversation. Developers who say yes to everything out of conflict avoidance end up with unprofitable projects; clients who understand the scope process get better outcomes because the developer can properly resource the work.
FAQ
How many revisions should be included in a standard web project?
There is no universal number. What matters is defining clearly what a "revision round" covers: design only, content only, or both. Most professional freelancers include 2–3 structured revision rounds. What is not acceptable is "unlimited revisions" as a selling point — it attracts clients who will abuse it and drives up effective project costs for everyone.
What if a client is never satisfied with revisions?
The contract should define a clear completion criterion — typically approval of a staged build against the validated mockups. A client who refuses to approve a build that accurately implements validated designs is in breach of the project agreement, not the developer.
