DEV Community: ScopePaid

Bug or change of mind? The 3-question test I run on every post-launch request

ScopePaid — Mon, 19 Oct 2026 13:13:21 +0000

Two weeks after a client signed off on a site, I got this:

Hey! Found a couple of bugs on the pricing page. Can you fix them today?

There were two. One was real: on a narrow phone the toggle between monthly and yearly overlapped the plan names. That was my mistake, and I fixed it that afternoon without charging.

The other was the headline. They wanted it bigger and in a different font, "because it doesn't pop." The headline matched the approved mockup exactly. Same size, same font, same everything.

Both were filed as "bugs" in the same message, with the same urgency. And for a long time I treated them the same way, too: I fixed everything, because arguing over one line in an email felt petty.

The trouble is that "small fixes" after launch don't stay small. They come one at a time, each one too minor to quote, and a month later you've redesigned half a page for free while the final invoice is still "being processed."

The word "bug" is doing a lot of work

Clients aren't being sneaky when they call a preference a bug. To them, anything they don't like right now feels broken. That's an honest feeling. It's just not the same thing as a defect.

So I stopped debating the word and started running every post-sign-off request through three questions before I reply.

The 3-question test

1. Does it fail to match what was approved?
Pull up the signed-off thing: the mockup, the spec, the ticket, the staging link they said "looks great" on. If the live version differs from it, that's on me. If it matches and they want something else now, that's a change.

2. Is it broken, or just different from what they'd pick today?
Broken means it errors, it misbehaves on a device or browser we agreed to support, a form doesn't send, data is wrong. "Different" means the colour, the copy, the layout, or a feature they've just thought of. Preferences can be great ideas. They're still new work.

3. Did the need exist at sign-off?
"Make the contact form send to our new sales inbox" sounds like a fix. But if the sales inbox didn't exist when we signed off, it's a new requirement. Nobody did anything wrong. Things changed.

If the answer to #1 or #2 points at me, it's a bug, and I fix it free and fast. Anything else gets the change reply. The unclear ones are covered further down.

The two replies

I keep both of these saved so I'm not writing them while annoyed.

For a real bug:

Thanks for catching this. The toggle overlap on small screens is a bug on my side. Fixing it today, no charge. I'll send a link once it's live.

Owning it quickly matters. It's also what makes the second reply believable.

For a change of mind:

Happy to change the headline. For reference, the current one matches the mockup you approved on [date] (link). Going bigger with a new font is a design change, so here's the impact:

- About [N] hours, [fee]
- Can be live by [day] once you reply "approved"

Nothing else is affected. Everything else stays as signed off.

No "per section 4." No lecture. Just the approved thing, what's different, and what it costs. Most clients reply "oh, fair" because they honestly forgot what they approved.

When I send both replies in the same thread, I fix the bug first and then send the change note. Fixing what's mine first shows I'm not hiding behind the spec.

When it's genuinely unclear

Some requests sit in the middle. The spec said "mobile friendly" and never listed which devices. The mockup never showed an empty state. Requests like that I usually split down the middle: I fix the minimum that makes it work and quote anything that goes past that. Then I write the missing detail into the next proposal, so it's clear next time.

If I can't tell, I say so: "This one's a grey area since the spec didn't cover it. I'll make it work properly free, but the extra animation you mentioned would be a change." People take that well. Pretending to be certain is what starts arguments.

The habit that makes this work: log it the day it arrives

The test only works if you can answer question #1 in thirty seconds. That means having the approved version and the request in one place, not spread across Slack, email, and a Figma comment from six weeks ago.

So every post-launch request gets one row the day it comes in:

Date received and who asked
Exact wording (pasted, not paraphrased, because paraphrasing is where "bug" quietly becomes "fix")
Approved reference (mockup link, spec line, sign-off email date)
Call: bug / change / grey area
Estimate (hours, even for bugs, so you can see what free fixes really cost you)
Client approved? (yes / no / pending)
Billed? (invoice number, or "goodwill")

The "goodwill" option matters. Sometimes I choose to do a small change free, and that's fine. Writing it down turns it into a decision I made, not something I forgot to bill.

A side effect I didn't expect: at the end of a project the rows tell you which parts of your proposals are too vague. If the "grey area" rows keep landing on the same thing, like responsive breakpoints or copy edits, that's the line to tighten in your next contract.

If you'd rather not build the columns from scratch, I put a free Scope Change Log spreadsheet together with these fields already set up (Google Sheets or Excel). A notes app works too. The point is to have the record, not to use any particular tool.

How do you handle the "it's a bug" message after sign-off? Do you fix everything up to a point, have a warranty window in the contract, or quote anything that isn't strictly broken? I'd like to know where other people draw the line.

The 4-line email that turns "quick asks" into change orders

ScopePaid — Thu, 24 Sep 2026 03:13:15 +0000

Scope creep almost never arrives as a formal change request.

It arrives as a Slack ping at 4:47pm:

Quick one can we also add X? Shouldnt take long.

If you answer in the thread, you’re negotiating from memory and goodwill. That is how unpaid hours get born.

Contracts help. Revision caps help. What still fails is the next message you send.

What I used to do

I’d type “sure” because I didn’t want to sound difficult. Then Id do the work. Then at invoice time I’d either eat it or invent a fight about something we never wrote down.

The fix wasn’t a tougher personality. It was a boring email I send before I touch the extra work.

The 4-line change-order email

Subject: Re: [Project] quick note on [short ask]

Hi [Name],

Happy to look at [short ask]. That’s outside what we scoped for [Project], so here’s the impact before I start:

 Effort: ~[N] hours → [fee]
• Timeline: +[N] working days (or: no date change if we swap [Y])
• Starts after you reply “approved”

In-scope work continues as planned either way.

Thanks,
[You]

That’s it. No PDF. No drama. No “per our agreement section 4.2.”

You’re not saying no. You’re giving them a decision.

Why this works better than arguing in Slack

It moves the ask out of chat instincts. Slack rewards speed. Email (or a short Loom + email) rewards a record.
Fee and timeline travel together. Quoting money without schedule impact is how you still blow the deadline.
“Approved” is the gate. Verbal “sounds good on a call is not a gate. A one-word reply is.
Tiny freebies stay intentional. If you want to gift it, send the same email with $0 and “goodwill this once.” They still reply approved. The habit stays intact.

What if they push back?

Usually one of three things:

“Can’t we just include it?” → Restate the original deliverables in one line, then re-offer quote / swap / defer. Don’t debate feelings; point at the list.
Silence. → Keep shipping the original scope. Park the extra. Follow up once: “Still happy to add this when you’re ready — original delivery stays on track.”
Just start, well sort money later. That’s how you fund their ambiguity. Reply: “I can start as soon as the change is approved (even at $0 if we’re calling it goodwill).”

Clients who hate any paper trail are telling you something useful early.

The 60-second habit around the email

Before you draft it:

Paste their ask into a note (date + exact wording).
Mark in / out / unclear against the SOW.
Estimate hours honestly (your first gut number is usually low add a buffer).
Send the email. Then wait.

If you start the work while the email is “pending,” you already lost.

Optional: keep the trail in one place

After a few projects, the emails alone get messy. I keep the same fields in a simple change log (date, ask, in/out, estimate, approved?, billed?) so I’m not hunting Slack when it’s time to invoice.

If you want a starting spreadsheet instead of building columns from scratch, heres a free Scope Change Log (Excel / Google Sheets): https://fluidoxygen.gumroad.com/l/vogjtv

Use it, fork it, or ignore the file the email is the product. The sheet just stops you from losing the receipts.

Curious what line you actually send when the 4:47pm ping hits. Do you quote every time, bundle “small” asks weekly, or absorb them until it hurts?

The awkward part of freelancing isn't the work — it's the follow-up

ScopePaid — Mon, 14 Sep 2026 23:08:55 +0000

Following up on an unpaid invoice is less about being pushy than being specific.

My simplest sequence:

Send a clear reminder before the due date.
On the due date, restate the amount, invoice number, and payment link.
If it slips, ask for a concrete payment date.
Keep the thread factual and easy to forward.

The awkward part is usually the silence. A small tracker helps me remember who needs a nudge and what I already said, so each follow-up feels like process—not emotion.

I put the tracker and scripts I use here: https://fluidoxygen.gumroad.com/l/mvcrwn

Stop Eating Free Scope: The Change Log Habit That Saved My Freelance Hours

ScopePaid — Mon, 14 Sep 2026 01:14:52 +0000

Scope creep rarely shows up as a formal change request. It shows up as a Slack ping at 4:47pm: "Quick one — can we also add X? Shouldn't take long."

You know you should pause. You also know saying yes keeps the relationship warm. So you say yes. Later there's no paper trail, and invoicing it feels awkward.

Contracts help. Revision limits help. What still fails is the moment between the ask and the work.

The 60-second pause

Before you start anything new mid-project:

Restate the original scope in one line
Classify the ask: in scope / out of scope / unclear
Give two paths: quote it, or defer to a later phase
Don't start until they confirm in writing (even a "yes" reply)

Tiny freebies are fine — if you choose them. Log them as $0 so they don't become invisible hours.

What I put in a change log

Date + who asked
What they asked (paste the message)
In / out / unclear
Est. hours and price (including intentional $0)
Approved? How?
Started only after yes

After a couple projects you see leakage in dollars instead of vibes.

A line that doesn't sour the client

"Happy to add that — it's outside what we scoped, so I'll send a quick estimate (hours + timeline) and start once you confirm."

You're not saying no. You're replacing memory with a record.

Free template

I packaged those columns into a free spreadsheet (Excel / Google Sheets) if you want a starting point instead of building it from scratch: https://fluidoxygen.gumroad.com/l/vogjtv

Use it, fork it, ignore it — the habit matters more than the file.

Curious how others handle the 4:47pm "quick ask." Do you log it, absorb it, or quote every time?