She Signed 'Reasonable Revisions.' It Turned Into Eleven Rounds.

A freelance designer signs a scope of work that says "logo design with reasonable revisions." Three weeks and eleven rounds later, she's still revising the same logo for the same fixed fee, because "reasonable" turned out to mean whatever the client decided it meant. The contract wasn't broken. It just never actually said anything.

This is how most scope creep starts. Not with a client acting in bad faith, with a phrase that sounded fine when it was signed and turned out to have no real boundary at all.

The fix is catching it before you sign: Spot the Vague Language in a Scope of Work Before You Sign It reads a contract the way a dispute eventually will, and flags every phrase that's going to cause one.

Why vague language is the real risk, not bad clients

Most scope of work documents get written fast, near the end of a sales conversation, by someone who wants to close the deal, not litigate every edge case. Phrases like "reasonable revisions," "ongoing support," or "minor changes" feel generous and collaborative at signing time. They only reveal their actual cost once a client interprets them differently than the freelancer did, and by then there's no clean way to point at the contract and settle it, because the contract never actually defined anything.

The freelancer isn't wrong to assume good faith. The problem is that a phrase like "reasonable revisions" has no shared definition. Two people can read it completely differently and both be acting reasonably from where they're standing. That's not a personality conflict, it's a drafting failure, and it's fixable before the contract is signed in a way it almost never is after.

How the prompt works

You paste in the scope of work text. It goes through looking specifically for language that's ambiguous in the way that causes disputes, not just any imprecise wording, but the specific patterns that tend to expand into unpaid work: vague revision counts, undefined "support," deliverables described without a countable unit, anything that could reasonably be stretched.

For each phrase it flags, it quotes the exact text, explains concretely how a client could interpret it more broadly than intended, and suggests a specific replacement that closes the gap. Not "be more specific," an actual rewrite: "reasonable revisions" becomes "up to 3 rounds of revisions, each round limited to changes within the original brief." It also checks for something most freelancers don't think to look for until it's too late: whether the document defines a change-order process at all, the actual mechanism that lets new requests become new billable work instead of expanding the original scope with no one noticing.

A worked example

Take a real scope of work line: "Website design and development, including reasonable revisions and ongoing support post-launch."

Run it through and three things get flagged. "Reasonable revisions" has no count, no boundary, and no definition of what counts as a revision versus a new request, the exact language that turned three weeks into eleven rounds in the story above. "Ongoing support post-launch" has no end date and no definition of what "support" covers, does that mean bug fixes only, or does it mean the client can ask for new features indefinitely. And there's no change-order clause anywhere in the document, so even if a request is genuinely new work, there's no defined path to bill for it separately.

The suggested rewrites: "up to 2 rounds of revisions within 10 business days of each draft, additional rounds billed at $X/hour" for the first, "30 days of bug-fix support post-launch, new feature requests scoped and quoted separately" for the second, and a short change-order clause added for anything outside the defined scope. Same project, same relationship, a contract that actually means something if a dispute ever comes up.

Where the value actually sits

This isn't really about catching dishonest clients. Most scope disputes involve two reasonable people who genuinely disagreed about what a vague phrase meant, and by the time that disagreement surfaces, there's no clean way back to a shared understanding. Fixing the language before signing means the disagreement either never happens, or happens against a contract specific enough to settle it in five minutes instead of an awkward month of back-and-forth.

It also changes the tone of the relationship going forward. A specific scope isn't a sign of distrust, it's what lets both sides know exactly where the line is, which is the thing that actually prevents the passive-aggressive slow-drift into unpaid work that damages more freelancer-client relationships than any single confrontation does.

How to use it

1. Before signing anything, paste the full scope of work or statement of work text into the prompt, not just the parts that feel uncertain, ambiguity often hides in the parts that read as boilerplate.
2. Run it through the prompt and go through the flagged phrases in the order it ranks them, riskiest first.
3. Send the specific rewrites back to the client as a normal part of finalizing the contract, not as a confrontation, "let's just tighten up a couple of these terms" is a completely standard thing to say before signing.

The version of this conversation that happens before signing takes five minutes and feels like due diligence. The version that happens after eleven rounds of unpaid revisions feels like a fight no one wanted to have. Same underlying issue, completely different cost, depending entirely on when it gets caught.