on my first few freelance projects, my contract had one big flaw: it treated delivery as a single event at the very end.
what always happened:
- client would say "looks good" on staging in week 2
- in week 5, right before launch, they'd ask to redo the entire homepage layout
- when i mentioned extra cost, they'd argue: "but the project isn't launched yet, so this is just part of it"
i lost so many weekends doing free reworks because of that loop.
now i do two simple things differently:
- every milestone is an isolated delivery. once stage 1 (e.g. design/auth) is approved, that code is locked. any changes after that are billed as an add-on.
- no verbal or slack sign-offs. i send a private link via Velloxis where they click to approve before i start writing code for the next stage.
it completely killed the "i never said it was final" argument.
how do you guys handle clients who try to redesign early features right before launch?
Top comments (1)
Hello Glad to see you, I am Kane Lim from Hong Kong. I have over 10 years of development experience. I am writing this because your post was interesting.
This is really a contract architecture problem rather than simply scope creep. I use milestone based acceptance criteria with explicit change control. Each milestone should define deliverables, acceptance tests, approval deadline, and a frozen baseline. Once accepted, changes create a new change request with impact analysis for cost, schedule, dependencies, and regression risk.
I also recommend keeping approvals and requirements in one auditable system rather than scattered across Slack. Versioned specifications, decision logs, and immutable approval timestamps make disputes dramatically easier to resolve.
The strongest improvement is separating defect remediation from requirement changes. A defect violates the agreed acceptance criteria. A redesign changes the specification.
Your approval workflow is a very practical solution. Clear boundaries protect both the client and developer while keeping the relationship professional.