Sign-off is the moment a project is supposed to end. In practice it's often where projects go to stall — one more small change, one more stakeholder who hasn't seen it, one more round that wasn't in the quote.
The cause is almost never a difficult client. It's a process that never defined what "approved" means or who gets to say it.
Why sign-off stalls
Nobody named the decision-maker. If four people can comment and none can approve, you don't have an approval process — you have a discussion that never resolves.
Late stakeholders. The executive who sees it for the first time in week eight will have opinions that reopen week three. Every project has this person; the only variable is whether you planned for them.
No definition of done. Without an agreed standard, "approved" is a feeling. Feelings move.
Undocumented decisions. If the decision to go with the teal header lives in a call nobody wrote down, it gets relitigated. Repeatedly.
Unbounded rounds. When revisions are implicitly unlimited, there is no reason for anyone to finalise their thinking.
None of these are fixed by working faster.
Set the frame before you design anything
Sign-off is decided at kickoff, not at the end.
Name one approver. One person whose yes is binding. Others advise; one decides. Put the name in the contract.
Agree the rounds. Three rounds included, further rounds billed at your hourly rate. Specific numbers, in writing.
Define what each round covers. Round one: structure and content. Round two: visual polish and bugs. Round three: confirmation only. This is what lets you say "that's a round one question" without it being a fight.
Agree the standard. What does approved mean — works on these browsers, at these breakpoints, with these pages complete? Vague standards produce vague approvals.
Get every stakeholder in at round one. Ask directly: who else needs to see this before it's signed off? Ask again before round two. Finding the fifth stakeholder in week eight is the single most expensive discovery in web projects.
Run rounds that converge
Each round should narrow the conversation. If round two reopens round one, the process isn't working.
Deadlines, not invitations. "Feedback by Thursday" gets responses. "Let us know your thoughts" gets silence, then everything at once on day ten.
Feedback on the real thing. Reviewing a static mockup produces different feedback than reviewing a live page with real interactions and real responsive behaviour. Getting clients onto the actual staging build surfaces the real objections earlier, when they're cheap. Our guide to getting feedback on a staging site covers the mechanics.
Feedback attached to elements, not described in prose. "The spacing under the third heading on the pricing page" is an email that takes four minutes to write and two minutes to decode. A click on that heading is unambiguous and takes five seconds. In pinreview, reviewers click the element and comment directly on the live site — no account needed, and unlimited free guests, so every stakeholder can be included rather than filtered by seat cost.
Separate bugs from opinions. These need different treatment. A bug is a defect to be fixed; a preference is a decision to be made. Mixing them in one list means preferences get treated as defects, which is how scope grows.
Document decisions as they happen
Most sign-off arguments are memory disputes.
Every decision — approved, rejected, deferred, out of scope — should be written down at the moment it's made, attached to the thing it's about. Not in a call summary, not in someone's notebook.
A tracked board does this as a side effect. Each item shows what was raised, when, by whom, and how it was resolved. When someone asks in week ten why the header is teal, the answer is a link rather than an argument.
This is also what makes an out-of-scope conversation calm. Tag the item when it arrives, show it in the change order later. Nobody feels ambushed.
Make the last round genuinely last
The final round should be confirmation only: does each fix from round two work? Not a fresh review.
Say that explicitly when you send it. "This round is to confirm the twelve items from last round are resolved. New requests will be quoted as a change order." Written in advance, it reads as professional. Said after new requests arrive, it reads as defensive.
Then close it formally. An email that lists what was delivered, references the agreed standard, and asks for a written yes. "Approved" in writing, from the named approver.
The handover that prevents post-launch drift
Sign-off isn't the end of the relationship, and pretending it is causes friction two weeks later.
Be explicit about what happens next: what's covered by a warranty period, what counts as a bug versus a new request, how they report issues after launch, and what ongoing support costs.
Leaving the feedback tool in place after launch is a genuinely good move here. The client keeps a way to report real bugs with full context, you keep them out of your inbox, and the line between "defect" and "new work" stays visible to both sides.
The bottom line
Sign-off closes when one person can approve, the rounds are bounded and defined, feedback lands on the real site with context, and every decision is recorded as it's made.
Set that frame at kickoff. It's much harder to introduce in week eight, which is exactly when you'll wish you had.