Past about round four, revisions stop improving the site and start consuming the project — and the reliable sign is that a change you asked for in round two has been reversed by round six. Three moves end the spiral, and all of them involve deciding rather than looking again.
What the spiral looks like from inside
It never feels like a problem while it’s happening. Each round is reasonable. Move the number up. Try the other photograph. The blue was better. Actually the first version was fine.
Then you notice the file is called home-v9-final-final, six weeks have passed, and the site isn’t live. Complaint records show where this commonly ends: a deadlock where your last change and their final payment block each other, sometimes for months.
The four signs it’s a spiral rather than progress
1. A change is being reversed. Something you asked for in round two has been undone in round six. This is the clearest possible signal — you’re now circling rather than improving.
2. New reviewers keep appearing. Round four introduces your brother’s opinion; round six introduces a friend’s. Each brings a fresh set of preferences that contradicts the last. Design decided by committee is the single most common cause of a stretched timeline, ahead of anything a developer does.
3. The feedback has become taste rather than function. Early rounds fix real things — a wrong number, a missing page, text that’s too small. Later rounds are about whether the section looks better slightly wider. The second kind has no natural end.
4. The developer’s replies are slowing. From their side, unlimited free rounds is unpaid work, so they deprioritise. That’s the mechanism by which a spiral becomes a stall.
Why “unlimited revisions” makes it worse
Where rounds were never numbered, two things happen simultaneously. You feel entitled to keep going, because that’s what unlimited means. And the vendor treats round five as goodwill and slows down.
Neither party is behaving badly. The absence of a number is doing the damage.
The three moves that end it
1. Write one final list and stop looking.
Every remaining item, numbered, in one message, ending with “that’s everything.” Then don’t open the site again until that round is complete. Reviewing seven times and sending one item each produces seven rounds; reviewing once and sending seven items produces one.
2. Separate must-fix from would-prefer.
| Must fix before launch | Can wait until after |
|---|---|
| Wrong phone number, or it doesn’t dial | Photograph choice |
| Contact form not reaching your inbox | Wording anywhere |
| WhatsApp button missing the country code | Colours |
| Anything factually wrong — prices, address | Section widths |
| Unreadable or slow on a cheap phone | Logo size |
Only the left column blocks launch. Everything on the right can be changed in minutes once the site is live — that’s the fact that dissolves most of the spiral.
3. Name one approver and a launch date.
One person decides; others may point out factual errors. Then a date, told to someone who’ll ask about it. External accountability is what makes a deadline function.
The launch bar
If the five items below hold, go live. Everything else is an improvement you can make next week with the site already working:
- Phone number correct and tappable
- Contact form reaching an inbox you check
- WhatsApp button opening a chat with your number, country code included
- Nothing factually wrong
- Readable and fast on a cheap Android phone on mobile data
Avoiding the spiral next time
Two lines in your scope message before work starts:
Two revision rounds included. Additional rounds at ₹[amount] each.
That’s not a restriction on you — it’s what allows a developer to schedule the work and gives both sides a defined finish. Vendors prefer it too, because undefined revisions are how they end up losing money and going quiet.
The uncomfortable part
If you recognise the spiral in your own project, the cause may not be the developer.
A site at version nine where the developer has done everything asked is a project without a decision-maker. That’s fixable today: one final list, one approver, one date. There’s a separate piece on this, and it’s worth reading honestly rather than defensively.
What to do this week
- Check whether any earlier change has been reversed.
- Write one final numbered list and send it, ending with “that’s everything.”
- Sort your remaining items into must-fix and can-wait.
- Name one approver out loud to everyone who’s been commenting.
- Set a launch date and tell someone outside the project.
If you want it done the certain way
Two revision rounds agreed in writing, one numbered list per round, and a stated launch bar — so the design phase ends and the site goes live. Everything else becomes a post-launch list, which is normal rather than a delay. WhatsApp us; we reply in about five minutes between 9am and 7pm.
Related reading
- “Unlimited revisions” — does anyone mean it?
- The final-10% standoff
- Is your own perfectionism keeping the site offline?
- Where should change requests be written down?
FAQ
How many website revision rounds are normal?
Two or three, agreed in writing before work starts. Past about round four, revisions typically stop improving the site and start consuming the project — the tell is an earlier change being reversed.
Why does my developer slow down after several revision rounds?
Because undefined rounds are unpaid work from their side, so the project gets deprioritised. Numbering the rounds upfront prevents this and is in both parties’ interest.
How do I end an endless revision cycle?
Send one final numbered list ending with “that’s everything,” separate must-fix items from preferences, name one approver, and set a launch date. Almost everything on a website can be changed in minutes after it’s live.
