DEV Community

Cover image for How I stop scope creep before it starts: a 5-question scope check for freelance devs (and a free Claude skill)
Klipora HQ
Klipora HQ

Posted on

How I stop scope creep before it starts: a 5-question scope check for freelance devs (and a free Claude skill)

Most scope creep does not arrive as a big, obvious request. It arrives as "while you're in there, can you also..." and a polite smile. Each one looks small. Together they turn a fixed-price project into unpaid work.

Here is the system I recommend for catching it early: five questions you answer before you quote or start, plus a script for the moment a client asks for more. It works for freelance developers, and it works just as well if you build with AI tools like Claude Code or Cursor, where adding "just one more feature" is so cheap to prompt that it feels free. It is not free: you still have to review, test, deploy and support it.

Why AI makes scope creep easier to miss

When a feature takes two hours to write by hand, you notice the cost. When an assistant drafts it in two minutes, the instinct is to say yes. But the drafting was never the expensive part. These are:

  • Understanding the requirement (and the three unstated requirements behind it)
  • Reviewing generated code you are going to be responsible for
  • Testing edge cases and fixing what the first pass missed
  • Deploying, documenting, and answering questions later

So the rule is the same as before: if it was not in the agreement, it is a change, and changes get a price and a date.

The 5-question scope check

Answer these in writing before you send a quote. If you cannot answer one, that gap is where the creep will come from.

1. What is the one-sentence outcome?

Not a feature list. An outcome a stranger could verify.

  • Vague: "Build a booking site."
  • Checkable: "Visitors can pick a time slot and pay a deposit; the owner gets an email and sees the booking in an admin page."

If the sentence needs the word "and" more than twice, you probably have two projects.

2. What is explicitly out of scope?

Write an "Not included" list. This is the most skipped step and the most useful one. Typical items:

  • Content writing, photos, translations
  • Third-party account setup and fees
  • Browser/device support beyond a stated list
  • Hosting, monitoring, and ongoing maintenance
  • Anything involving data migration from an old system

Clients rarely argue with a list they saw before work began. They often argue with one you produce after the fact.

3. How many revision rounds are included, and what counts as one?

"Unlimited revisions" is the most expensive phrase in freelancing. Pick a number (two is common), and define a round: one consolidated set of feedback, delivered together, within five working days. Feedback that trickles in one message at a time is not a round, it is a stream.

4. What do you need from the client, and by when?

Most schedule slips come from waiting on logos, API keys, copy and approvals. List each dependency with an owner and a date, and state what happens if it is late (for example, the delivery date moves by the same number of days).

5. What is the acceptance test?

Decide how "done" is determined. A short list of three to eight checks the client can run themselves works well:

  • A new user can complete the signup flow on the staging URL
  • The contact form delivers to the address in the brief
  • The pages listed in the sitemap exist and load on the supported browsers

When those pass, the project is delivered. New ideas after that point are a new piece of work.

A quick checklist you can paste into your proposal

  • [ ] Outcome in one verifiable sentence
  • [ ] "Not included" list written down
  • [ ] Revision rounds: number and definition
  • [ ] Client dependencies with dates
  • [ ] Acceptance checks agreed
  • [ ] Change process described (how requests are priced and approved)
  • [ ] Payment milestones tied to deliverables, not to elapsed time

The sixth line matters most in practice. If your agreement says "requests outside the scope are estimated and approved in writing before work begins," then your reply to a new request is not a negotiation, it is just following the process you both agreed to.

What to say when they ask "can you also add...?"

The goal is to sound helpful, not defensive. Three moves: say yes to the idea, separate it from the current scope, and give a clear next step with a price and a timeline impact.

Here is a template you can adapt:

Hi Sam, thanks for sending this over. Adding [feature] is definitely doable.

It sits outside the scope we agreed (the agreement covers [one-line outcome]), so I'd handle it as a small change order. I estimate [X hours / $Y] and it would move delivery from [date] to [date].

Two options:

  1. Add it now, and I'll send a one-page change order for your approval first.
  2. Keep the current plan on schedule and I'll add it to a follow-up phase.

Which do you prefer? Once I have your reply I'll go ahead.

Why this works:

  • It does not say no. It says "yes, with a price," which is honest and usually well received.
  • It names the effect on the date. Clients often drop a request once they see it delays the launch.
  • It offers a choice. Two options feel collaborative and keep the decision with the client.
  • It is in writing. You can point to it later if there is a disagreement.

For truly tiny asks you can still say yes, on purpose: "Happy to include this one at no charge. Future additions like this would go through a change order."

Where an AI assistant helps (and where it doesn't)

An assistant is useful for the dull parts: turning a messy client brief into the five answers above, drafting the "not included" list, and flagging vague words like "simple", "standard", "etc." or "integration" that hide work. It is not a replacement for your judgment about price or your relationship with the client. Treat its output as a first draft you edit.

I packaged the five questions as a small Claude skill that takes a brief and returns an outcome sentence, out-of-scope list, open questions and risk flags. The link is at the bottom.

A short example

Brief from a client: "We need a simple dashboard for our team with login, some charts, and exports. Should be quick."

Run the check and the gaps show up fast:

  • "Simple," "some charts" and "exports" are undefined. How many charts, from what data source, and which export formats?
  • "Login" could mean email and password, SSO, or roles and permissions. Those are very different efforts.
  • No acceptance test. No named person who approves.
  • Out of scope was never discussed: data cleaning, hosting, mobile layout.

None of that is the client being difficult. It is just normal incompleteness. Asking these questions before the quote turns surprise work into priced line items.

Takeaway

Scope creep is mostly a documentation problem, not a people problem. Write down the outcome, exclusions, revision rules, dependencies and acceptance checks first, and answer new requests with "yes, here is the price and the date impact," in writing.

If you have a phrase or process that works for you, I'd like to hear it in the comments.


I'm building small tools for this problem at KLIPAURA. The free Scope Check skill is open source: https://github.com/KliporaHQ/scope-check-skill. There are also paid kits at https://klipora.gumroad.com (disclosure: that's mine).

Top comments (0)