How I Structure a Post-Launch Support Window So It Doesn't Become Unpaid Work

"We'll do two weeks of post-launch support" used to mean, in practice, that I kept quietly fixing things for a month and a half because the client kept finding small issues and it felt petty to say the window had technically closed.

The problem wasn't generosity, it was that the window had no structure — just a vague time period with no defined scope for what counted as "support" versus new work. Everything that surfaced in that window felt like it belonged, because nothing had been defined as not belonging.

An undefined support window isn't a boundary, it's just a delay before the real negotiation starts.

The structure that fixed it

• Support window scope is written explicitly: bug fixes to delivered functionality only, no new features, no scope not already in the original deliverable.
• A fixed calendar end date stated in the contract, not a rolling 'two weeks from launch' that drifts if launch slips.
• A daily or twice-weekly check-in cadence during the window instead of an open Slack channel, which naturally batches small issues instead of letting them arrive as constant interruptions.
• A written note sent at the window's actual close, summarizing what was covered, so there's a clear, documented moment where the free period ends.

The closing note turned out to matter more than I expected. Ending the window silently meant the next "quick fix" request arrived with the client still assuming they were inside it. Ending it with an explicit message — here's what we covered, the support window has now closed, here's how new requests get handled going forward — gave both of us a clean line to point back to.

Clients haven't pushed back on this once it's written into the contract up front. The pushback only ever came when the boundary was vague enough that reasonable people could disagree about where it was. Specificity, not strictness, is what actually protects a support window from becoming unpaid project extension.