The biggest mistake i made with client contracts (and how i fixed scope creep)

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:

1. 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.
2. 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?

Comments

[Kane Lim]

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.

[Aldo Barbosa]

the defect vs. requirement-change distinction is the sharpest part of this. most of my disputes weren't really about the milestone approval at all, they were about which bucket a request fell into, and that ambiguity is what let clients relitigate things.

curious about the impact analysis step, do you do that formally for every change request even small ones, or only above a certain size? I've found clients get frustrated if minor tweaks require the same overhead as big ones, but skipping it for "small" changes is exactly how scope creep sneaks back in.

[Kane Lim]

For small cosmetic changes, I record the request, affected component, and estimated effort directly in the change log. For anything touching data models, APIs, authentication, architecture, integrations, or previously approved acceptance criteria, I do a formal impact analysis covering dependencies, regression surface, delivery time, and cost.

The useful threshold is not really hours or dollar value. It is blast radius. A two minute database change can carry more risk than a two hour UI adjustment.

I also keep a running change budget for minor requests. Once that allowance is exceeded, the next request automatically becomes a formal change order.

That keeps the process lightweight for clients while preserving a clear audit trail. In practice, it has worked much better than making every change feel like bureaucracy.