Published 2026-09-10 · Updated 2026-09-10 · Adrieluxe Team
The Client Keeps Changing Requirements Before You've Signed
One or two rounds of a client refining what they want before signing is normal — it's what a client doing real work on the decision looks like. The pattern worth catching is different: does each new version of the ask remove anything, or does it only ever add? A brief that gets shorter and more specific each round is converging. A brief that only grows, with the same deadline and budget attached the whole time, isn't finalizing scope — it's previewing, for free, exactly how this client will behave once there's a contract and a clock running.
TL;DR
Track versions, not vibes: does each revision remove as much as it adds (genuine narrowing — proceed), only ever add with the budget and deadline untouched (scope inflation — the same pattern you'd call scope creep after signing, just showing up early), or contradict the last one because a different stakeholder answered (a Stakeholder Position gap, not a scope problem)? By the second revision, restate the scope in writing yourself and price anything past that as a change order, even before a contract exists — how the client responds to that boundary is a stronger signal than any individual change they've asked for.
Why a moving target is a different problem than a vague brief
A vague brief is ambiguous once — the fix is asking the right question and getting a clear answer back. A moving target is already clear, repeatedly, and then changes anyway. That's a pattern playing out over multiple exchanges, not a single gap you can close with one clarifying question, which is what makes it easy to miss: each individual revision looks reasonable in isolation, and it's only the sequence that reveals anything. PMI's Pulse of the Profession found 52% of projects experience scope creep, with an average 27% cost overrun — and that figure is measured after contracts are signed and work is underway. The mechanism is identical before signing; it's just still free to notice, because no hours are billable yet.
The three patterns, and which one you're actually in
Not every changed brief is the same problem. The test is what each new version does to the one before it — adds to it, replaces part of it, or contradicts it.
Genuine narrowing
Each round removes as much as it adds
The client drops an idea after thinking it through, trades one deliverable for another, or trims scope once you've named a rough price. The brief gets shorter, more specific, or both. This is what a client actually doing the work of deciding looks like — proceed, and treat the final version as genuinely final.
Scope inflation
Each round only adds, and the deadline and budget never move
Version two has everything version one had, plus something new. Version three has everything version two had, plus something else. Nothing is ever traded away, and the client hasn't revisited the price or the date to match. This is the pattern that predicts identical behavior after signing — the only thing that changes once there's a contract is that the additions start being called scope creep instead of feedback.
Indecision by committee
The ask contradicts itself because a different person answered this time
Version two doesn't build on version one, it disagrees with it — a different stakeholder replied and gave a different answer to the same question. This isn't a scope problem at all; it's an unresolved Stakeholder Position gap wearing a scope costume. No amount of clarifying the brief fixes it, because the brief was never the thing that was unclear.
The cheap test: number the versions, don't just remember them
It's hard to spot inflation from memory alone, because each single message reads as a small, reasonable ask. Label every version of the brief v1, v2, v3, and diff each one against the last — what got added, what got removed. Three or more versions in with nothing ever removed is the pattern, regardless of how reasonable any one version sounded on its own.
There's a reason this is easy to miss in the moment: every new version a client sends functions as a fresh reference point for what "normal" looks like, whether or not it actually is. Harvard's Program on Negotiation describes this as the anchoring effect — the tendency to judge each new offer against the most recent one instead of the original terms. Left unmanaged, a client who keeps sending new versions is quietly resetting the baseline every time, and v5 ends up getting compared to v4 instead of to what was actually agreed at v1.
Restate the scope in writing after every revision. It's the cheapest way to make sure the next change gets compared to what was actually agreed, not to whatever was said most recently.
What to actually do about it, before there's a contract to protect
The same three moves that apply to any single red flag apply here — reprice, rescope, or walk away — the only difference is what triggers the decision: not one flag in a single brief, but the count of un-narrowed revisions. In practice, that means: after the second revision, send back a short, written recap of the current scope yourself, and say plainly that anything past this point is a paid change order — the same language you'd use mid-project, just moved earlier, while it still costs you nothing to say. A client who's been narrowing in good faith agrees without friction. A client who's been inflating reacts to that boundary exactly the way they'd react to a change order after signing, which is the answer arriving early enough to still be useful.
Related reading
If the brief hasn't changed yet and you're reading it for the first time, start with 12 red flags in a client brief. If it's a single vague ask rather than a moving one, run it through the vague-brief triage playbook first. Once you've spotted a single flag — moving target or otherwise — and need to decide what to do about it, see you found a red flag — now what?. For the version of this same pattern that shows up after you've already quoted, see how to spot scope-creep risk before the project starts. For the full scored workflow all of this feeds into, see Client qualification: the complete guide.
Frequently asked questions
Yes — one or two rounds of narrowing or clarifying is a healthy sign the client is actually thinking it through, not a red flag. The pattern to watch for isn't change itself, it's whether each round removes anything. A brief that gets clearer and shorter as it's revised is converging. A brief that only ever grows, with the same deadline and budget attached, isn't converging — it's previewing what happens after you sign.
That's its own pattern, not a variant of scope inflation, and worth naming separately. If version 3 contradicts version 2 because a different stakeholder answered this time, the actual gap is Stakeholder Position, not scope — you don't yet know who the brief actually belongs to. The fix is to ask directly, before any more revisions: who is the one person whose sign-off ends this process? A moving target driven by an unclear decision-maker resolves once you find that person, unlike a moving target driven by simple scope inflation.
There's no fixed number that works for every project, but the diagnostic that holds up in practice is simpler than counting rounds: by the second revision, restate the scope in writing yourself and price anything past that as a change order — even before a contract exists. Clients who accept that boundary were narrowing in good faith. Clients who push back on pricing a third revision, the same way they'd push back on a change order mid-project, have already shown you the real answer.
It's the same failure mode showing up earlier, which is exactly why it's worth naming separately. Scope creep is usually discussed as something that happens after a contract is signed and work has started. This is the identical pattern — the ask quietly growing round after round — but visible before you've committed a single billable hour, which means it's still free to notice and cheap to address. Missing it here doesn't prevent scope creep, it just delays it until the stakes are higher.
Not as a standalone free tool — comparing multiple versions of an ask against each other is a different task than scoring a single brief. If you're already running a brief through Pre-Sales OS, the rescore feature re-runs the same analysis with the new version added as context, on the same record, for free — so you can watch the risk score move (or not) each time the ask changes, instead of relying on memory for whether it's actually drifting.
Watch the risk score move each time the ask changes.
Comparing multiple versions of a brief against each other isn't something a single free scan can do — but Pre-Sales OS's rescore feature re-runs the same analysis with the new version added as context, on the same record, for free. Instead of trusting memory for whether a brief is actually drifting, you get the same risk score run again against what changed.
Try Pre-Sales OS free