Nothing Is Ever 'Quick' After 11 PM: Defusing the After-Hours Fix Request
It's 11:07 PM. You just got your dev environment humming, coffee number two is still warm, and your phone buzzes. It's a client. "Hey, quick question — can you fix the button real quick? No rush."
Both of those sentences are lies, and you know it.
Why the 'Quick Fix' Is Never Quick
Here's the psychology: when a client says "quick," they're describing their effort, not yours. They typed the message in ninety seconds, so in their head, the job is ninety seconds. What they're not picturing is you spinning up the local environment, reproducing the bug, tracing it through three layers of JavaScript nobody has touched since the redesign, deploying, and testing on mobile Safari because of course it's a mobile Safari issue.
The late-night timing makes it worse. A "quick fix" request at 2 PM on a Tuesday is a task. The same request at 11 PM carries an invisible deadline — the client is clearly still at their desk, still thinking about it, and probably hoping to see it resolved before they log off. The word "no rush" is doing a lot of load-bearing work in that sentence.
And there's a sneakier layer: the after-hours ask quietly resets expectations. Respond once at 11:30 PM and you've just taught the client that you answer at 11:30 PM. Congratulations, you're now on call.
The 10-Minute Triage Rule
Before you touch the keyboard, run the request through a quick triage:
- Is production down? If the checkout page is throwing a 500 error, that's not scope creep — that's an emergency, and emergencies get different treatment (and different rates).
- Is it actually in scope? A broken button from the build you shipped last week is a warranty fix. A "broken button" that turns out to be a new feature request wearing a trench coat is billable work.
- Can it wait until morning? Ninety-five percent of after-hours requests can. The client just doesn't want to be the one who says so out loud.
If it's not down, not in scope, and can wait — it waits. Your only job tonight is to send the right reply.
Templates That Hold the Line
For the out-of-scope ask:
"Got it — I'll take a look first thing tomorrow. Quick note: this looks like a new feature rather than a fix to the original build, so I'll put together a short estimate for the additional work and send it over in the morning."
Notice what this does: it doesn't say no, it doesn't apologize, and it quietly flags that this is new work with a price tag. No work gets done, and the client is already pre-conditioned for an invoice.
For the in-scope bug that can wait:
"Thanks for flagging — I'll get eyes on this in the morning and confirm once it's resolved. If anything's down or blocking customers tonight, let me know and we can treat it as a rush item at the emergency rate."
That last clause is your pressure-release valve. You're not refusing to help; you're offering a priced path for genuine urgency. Most clients, faced with a dollar figure, suddenly discover their issue can wait until 9 AM.
Pricing the Rush Honestly
If you do take after-hours work, price it like the disruption it is. A simple formula that holds up:
Base hourly rate × 1.5, with a two-hour minimum.
The multiplier isn't punishment — it's compensation for the schedule you're giving up, the context-switching cost, and the fact that tired code is expensive code. The two-hour minimum exists because "quick fixes" have a documented habit of unfolding into three-hour odysseys the moment you open the file. If it genuinely takes twenty minutes, the client gets a pleasant surprise. That's a good place for the surprise to live.
Put the rush rate in your contract before anyone needs it. A rate negotiated at 11 PM over a panicked email is a rate you're losing on. A rate agreed to in a signed proposal on a calm afternoon is just business.
Boundaries Don't Lose Clients — Resentment Does
The fear underneath every ignored 11 PM email is "what if they leave?" Here's the thing: clients don't leave developers who respond promptly during business hours, deliver solid work, and communicate clearly about availability. They leave developers who burn out, get snippy, and start shipping sloppy code because they've been running on four hours of sleep for a month.
A developer with stated hours and a rush rate reads as a professional. A developer who answers everything at all hours reads as either desperate or disorganized — and eventually gets priced accordingly, in both directions.
Set an auto-responder after 8 PM. State your hours in your email signature. Enforce the minimum. The clients worth keeping will respect it, the ones who won't were going to be a problem anyway, and you'll still be writing good code at sunrise.
Now close the laptop. That button will still be there at 9 AM — and so will your rate card.
