Stop working for free: a freelancer system for paid follow-ups (scope creep, support, and “quick requests”)

Why freelancers end up working for free (especially for previous clients)

Free work doesn't usually start as "I'm going to be exploited today." It starts as one of these:

1) Ambiguous scope makes everything feel "included"

If you never wrote down what was included (and what wasn't), the client will fill in the blanks with their own assumptions.

Result: you get "Can you also…" requests that technically might be reasonable, but were never priced.

2) No end-of-project closeout means the project never ends

Many freelancers deliver the final file and… fade out. No closeout email. No "this engagement is complete" note. No next-step offer.

Result: the client treats you as "still on the project" indefinitely.

3) You confuse being easy to work with and being free to work with

Clients love reliability. Unfortunately, "reliable" can drift into "always available" if you don't define boundaries.

Result: you answer fast, fix fast, and accidentally train the client that requests are free.

4) You don't have a paid option that feels simple

If the only way to charge is to write a whole proposal, create a new contract, and do a big negotiation… you'll avoid charging for small things.

Result: you do the small thing for free because the billing process feels heavier than the work.

None of these require a personality transplant. They require a system.

The 3-bucket rule: Included / Warranty / New Work

This is the simplest "stop working for free" framework that actually holds up in real life:

Bucket A: Included

Work that is explicitly included in the current agreement (SOW, contract, or retainer scope).

Example: You're on a monthly retainer that includes "two landing page updates" and the request is exactly that.

Action: do the work. Track it. Deliver it.

Bucket B: Warranty

Work that fixes a defect you introduced, inside a defined window, under defined conditions.

Important: warranty is not "unlimited support forever." Warranty is a bounded commitment. If you never defined it, you're basically offering unlimited warranty by accident.

Example: You shipped a website, a form stops submitting because of something you changed last week, and you're within your warranty window.

Action: fix it promptly, document the fix, close the loop.

Bucket C: New Work

Anything that is not explicitly included, anything after the engagement ended, or anything that changes deliverables/timeline/assumptions.

Example: "Can we add a new page?" "Can you jump on a call and brainstorm?" "Can you update this file?" (after the project ended)

Action: route into a paid path (quote, change request, support block, or retainer).

The key line to remember: if it changes the plan, it's new work.

The Free Work Firewall: four gates that stop unpaid work

A good system isn't "be tougher." It's a series of gates that make unpaid work hard to accidentally do.

Gate 1: Intake (no more requests in random places)

If requests arrive via Slack DMs, texts, or "quick calls," they feel informal. Informal requests are where free work thrives.

Your goal: one official intake channel.

Practical options:

• One email address ("support@" or "projects@")
• A simple form (even a Google Form) that creates an email
• A ticketing system if you have one (not required)

Script: move the request into the right channel

Thanks — can you email this to [address] so I can track it and reply with next steps?
I want to make sure it doesn't get lost.

Gate 2: Classification (3 buckets, always)

Every incoming request gets classified as Included, Warranty, or New Work.

Script: confirm the bucket before committing

Happy to take a look. Quick check first: is this within our current scope/retainer, or is it a new request since the project wrapped?
Either way is fine — I just want to route it correctly.

If you're not sure, treat it as New Work until you can confirm otherwise. You can always "downgrade" to Included/Warranty once it's clear.

Gate 3: Pricing path (make paying easy)

If paying requires a big negotiation, you'll keep doing free work. So your pricing path has to be lightweight.

Pick one of these defaults:

• Hourly support with a minimum (e.g., 1-hour minimum, billed in smaller increments after)
• Prepaid support blocks (e.g., 5 hours prepaid)
• A maintenance/support plan (monthly, billed in advance)
• A micro-SOW for small projects (one page, short)

The goal is not the perfect model. The goal is a model you will actually use.

Optional: the two-lane support model (so you stop feeling guilty)

If you currently offer free help to past clients, moving to paid support can feel like you're "abandoning" them. A two-lane model makes the boundary practical and fair:

• Lane 1: Active / retainer clients get priority scheduling and faster response times because they're paying to reserve capacity.
• Lane 2: Ad-hoc / previous clients are still supported, but on a best-effort basis (and only through the paid path).

Write the lane rule down once (in your closeout email and your support policy) so you don't have to renegotiate it in every inbox:

Support requests are handled via [intake channel]. Retainer clients receive priority scheduling.
Ad-hoc requests are scheduled as capacity allows and are billed at the standard support rate.

This helps in two ways: the client sees the logic (priority is purchased), and you stop "making exceptions" out of guilt.

Gate 4: Approval (no approval, no work)

Approval can be:

• a signed change request
• a paid invoice (prepay)
• a "reply approved" to a written estimate
• an active retainer in good standing

What it cannot be: a vague "sure" on a call with no written record.

Script: make approval explicit

Great — if you reply "approved" to the estimate below, I'll schedule it and get started.
(If you'd rather put this on a monthly support plan, I can send that option too.)

This is the gate that stops "we'll figure it out later" from becoming "you did it for free."

Scripts: what to say when a previous client asks for something "quick"

Most free work starts with one phrase: "Sure, I can do that." Your replacement is: "Sure — here's the process."

Use these scripts as templates, not as commandments.

Script 1: The default "small request" response (turn it into paid work)

Happy to help. This looks like new work outside the original scope, so I can handle it as a small support task.

Option A: Ad-hoc support — [$X minimum] / [$Y per hour], scheduled within [timeframe].
Option B: Monthly support — [$Z/month] for [defined cadence/scope], with priority turnaround.

Which option do you prefer?

Script 2: When you need to investigate first (paid diagnosis)

Sometimes the request is "Can you fix this?" and you genuinely don't know what's wrong yet. The trap is investigating for free.

I can take this on. Because the root cause isn't clear yet, the first step is a short diagnosis pass.
I can do a [60–90 minute] investigation for [$X]. After that I'll reply with (1) what I found and (2) an estimate to implement the fix.

Script 3: When it's warranty (be generous, but bounded)

Thanks for flagging this. If it's related to what we shipped and within the warranty window, I'll fix it.
Can you send steps to reproduce (and a screenshot/video if possible)? I'll confirm once I can reproduce it and aim to have a fix by [date].

Script 4: When they want a call (calls are work)

"Can we hop on a quick call?" is usually billable consulting disguised as coordination.

Yes — happy to talk it through. I do ad-hoc calls as paid consulting.
Here are two options:
- 30-minute call: [$X]
- 60-minute call: [$Y]

If you'd rather keep it async, you can email the questions and I can quote the work instead.

Script 5: When they say "It'll only take you a minute"

The correct response is not "You're wrong." The correct response is "Even small things have a process."

I can do it — small changes still go through my support process so we keep scope and billing clean.
I can send an ad-hoc support invoice for [$X] and start once it's paid.

How to reset expectations with existing clients (the "policy update" email)

Many freelancers avoid changing the pattern because they're afraid of awkwardness. The awkwardness is real, and it's also finite. The only way out is a clean reset.

You are not asking permission to charge. You are informing them how requests are handled going forward.

Template: policy update for previous clients (copy + adapt)

Subject: Quick update on how I handle follow-up requests

Hi [Name] — quick note as we've wrapped [project / phase].

Going forward, any new requests outside the original scope are handled through my support process so timelines and billing stay clear.

Options:
1) Ad-hoc support: [$X minimum] / [$Y per hour], scheduled as capacity allows.
2) Monthly support plan: [$Z/month] for [defined scope/cadence], with priority turnaround.

If something is a bug related to the original delivery and within the warranty window, I'll of course fix it.

The easiest way to send requests is: [one intake channel].

Thanks,
[Your name]

Packaging options that turn free work into paid work

Your paid path should match the shape of the requests you get. Here are the models that work well for previous-client follow-up work.

Option 1: Hourly support with a minimum

Best when:

• requests are unpredictable
• you don't want to sell a monthly plan yet
• you want to make charging easy

Simple default:

• 1-hour minimum
• billed in smaller increments after
• paid upfront for small tasks (or invoiced weekly if trust is high)

This eliminates the "it took five minutes" debate because you're pricing access and context-switching, not only execution time.

Option 2: Prepaid support blocks

Best when:

• the client sends batches of small work
• you want to reduce invoicing overhead
• you want the client to think before requesting

Example structure:

• 5-hour block prepaid
• expires in 60–90 days (so it doesn't become a lifetime liability)
• priority scheduling compared to ad-hoc

Option 3: A maintenance plan (for work you built)

Best when you built the thing (site, app, system) and the client needs ongoing updates, security patches, or monitoring.

A maintenance plan should define:

• what is included (updates, backups, monitoring, small fixes)
• what is not included (new features, redesigns, strategy work)
• response times (business hours vs on-call)
• how requests are submitted (intake channel)
• how extra work is handled (hourly or change request)

Maintenance plans fail when they're vague. If it sounds like "help as needed," it will inevitably become unlimited support.

Option 4: A retainer (for ongoing outcomes)

Retainers work when you can define cadence and boundaries. Make the type explicit:

• Capacity retainer: reserve X hours/days per month.
• Deliverable retainer: ship a defined set of outputs monthly.
• Access retainer: office hours/reviews/advisory (not unlimited production).

Retainers fail when the scope is implicit. If you can't explain what's included in one paragraph, the scope will expand.

Prevention: stop free work at the contract + offboarding stage

The best time to stop working for free is before the free request arrives.

1) Put boundaries in the SOW (especially out-of-scope)

Your SOW should make these things explicit:

• what is included (deliverables)
• what is excluded (out-of-scope list)
• how revisions work (limits)
• how change requests work (approval step)
• what happens after delivery (warranty window + support options)

If you only do one edit: add an out-of-scope section that names the most common assumed extras.

2) Define a warranty window (even a simple one)

Warranty is a business decision. It protects trust when you make a mistake. It also prevents the "forever" expectation.

A common pattern:

• warranty covers defects you introduced
• window is time-bounded (e.g., 7–30 days)
• excludes new features, third-party changes, and "it worked before" mysteries without reproduction steps

3) Run a closeout sequence (so the engagement actually ends)

At the end of a project, send a closeout email that includes:

• what was delivered (final list)
• where files/docs live
• warranty window (if any)
• how future requests are handled (paid support lane)

Template: closeout note that prevents free work

Subject: [Project] wrap-up + next steps

Hi [Name] — we're wrapped on [project]. Final deliverables are here: [link].

Warranty: if you spot a defect related to what we shipped within [X days], I'll fix it.
New requests outside scope are handled via ad-hoc support or a monthly plan (details below).

Ad-hoc support: [$X minimum] / [$Y per hour]
Monthly support: [$Z/month] for [scope/cadence]

To submit requests, email: [one intake channel].

Thanks,
[Your name]

FAQ

"Won't charging for small things ruin the relationship?"

Usually not, assuming you do it calmly and consistently. Most clients prefer a clear process to an awkward guessing game. The relationship is more likely to be damaged by resentment than by a simple, predictable policy.

"What if it's my fault?"

If you introduced a defect, fixing it is part of professionalism. That's what warranty is for. The point is to define warranty so it stays bounded.

"What if I already set a precedent by doing free work?"

Precedent is real, but it's not permanent. Reset once with a policy update and then enforce consistently.

"How do I handle urgent requests?"

Urgency is a constraint, not a reason to work for free. Offer an expedited option with a premium and a clear tradeoff (what gets deprioritized). If you can't accommodate, offer the soonest realistic slot.

The point (so you don't turn into a robot)

The goal isn't to never help previous clients. The goal is to stop improvising help in a way that quietly donates your time. A clear support policy lets you stay warm and responsive without becoming an unpaid help desk.

When a request comes in, you don't debate your worth. You run the system: classify it, route it into a paid path, get approval, then deliver. Consistency is what makes this feel normal to clients, and what makes it sustainable for you.

Tools and templates