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.
Top comments (0)