Skip to main content
Out of Scope

is ongoing site maintenance out of scope after launch?

Yes — unless your contract explicitly bundles a support window or a retainer, post-launch maintenance is a separate engagement. The narrow exception is a short warranty period for defects you shipped, which covers fixing your own bugs but not new requests or routine upkeep.

Why this answer

A build contract delivers a working thing at a point in time. Maintenance is a different shape of work entirely: it's open-ended, recurring, and tied to forces outside the original deliverable — dependency updates, security patches, hosting hiccups, browser changes, content swaps. None of that was priced into a fixed project fee, because none of it has a fixed end. When a client assumes you'll 'just keep an eye on it' after launch, they're quietly converting a one-time deliverable into an indefinite service relationship without paying for the difference. The two activities also carry different risk profiles. Building is bounded; you scope it, finish it, hand it off. Maintenance asks you to stay on the hook for problems you didn't cause and can't predict. Treating that as a courtesy bundled into the build fee means you're underwriting the client's operating costs out of your own margin, every month, forever.

When the answer flips

This becomes In Scope when the contract names a support or warranty window — say, thirty days of post-launch fixes — though that window almost always covers defects in what you delivered, not new features or content changes. It also flips if you signed a retainer or a care-plan agreement alongside the build, in which case maintenance was paid for upfront and the only question is whether a given task fits the retainer's hours. A genuinely gray case is the line between a bug and a change: if the contact form stops sending after a host migration you performed, that's arguably your defect; if it stops because the client switched email providers, that's new work. When the cause traces back to your delivery, lean toward covering it.

What to do next

Separate the two conversations cleanly. First, confirm whether any open warranty window applies and honor it without fuss — fixing your own defects builds trust. Then, for everything ongoing, propose a maintenance retainer with a defined monthly scope: updates, backups, uptime checks, and a set number of small-change hours. Price it as a recurring fee, not per incident, so the client buys predictability and you buy a steady baseline. Try language like: 'The build contract covers delivering the site; keeping it healthy after launch is ongoing work I handle through a monthly care plan — here are the tiers.' Offer two or three levels so the client self-selects. If they decline a retainer, make it explicit in writing that post-launch requests will be quoted individually, so the next 'quick favor' starts from a clear baseline.

Settled reads your contract and gives you the exact verdict for this situation — try it free →

Frequently asked questions

What's the difference between a warranty fix and paid maintenance?+

A warranty fix corrects something you delivered broken — a layout that breaks on mobile, a feature that never worked as specced. Paid maintenance handles everything that arises after a correctly delivered build: dependency updates, new content, third-party changes, performance tuning. The test is causation. If the problem traces to your original delivery, it's a warranty matter. If it traces to time passing or the client's evolving needs, it's maintenance.

How should I price a maintenance retainer?+

Price for predictability on both sides. Pick a monthly fee that covers a defined set of recurring tasks plus a capped pool of small-change hours, and state clearly what falls outside it. Tiered plans work well: a basic tier for updates and backups, a higher tier that adds a few hours of changes. Avoid pure per-incident billing for ongoing care — it punishes the client for reporting problems and leaves your income lumpy.

The client assumed maintenance was included. How do I push back without souring the relationship?+

Don't argue about what was 'understood' — point at the contract's deliverables and frame upkeep as a service, not a dispute. Something like: 'The agreement covered building and launching the site, which is done. Keeping it patched and current is ongoing, so I run that as a monthly plan.' Most clients accept this once it's framed as a normal industry practice rather than a surprise charge.

Do I have to keep a site secure for free after launch?+

No. Security patching is recurring, unbounded work that depends on third-party disclosures you don't control, so it belongs in a maintenance agreement. That said, if you delivered a site with a known vulnerability baked in at launch, that's a defect worth fixing under warranty. The ongoing job of staying ahead of new threats is a paid responsibility.

What if the client only wants help occasionally, not a monthly plan?+

Offer ad-hoc support at a higher hourly or per-task rate than your retainer equivalent, and reserve no guaranteed response time. The premium reflects that occasional work forces you to context-switch back into a project you've moved on from. Make clear that retainer clients get priority, so the pricing nudges anyone with real ongoing needs toward the plan.

How do I prevent this assumption on the next project?+

Add a short clause that states the build ends at acceptance, names any warranty window and exactly what it covers, and points to a separate maintenance agreement for ongoing care. Say it out loud during kickoff too — 'after launch, upkeep moves to a monthly plan' — so the expectation is set before anyone is invested. A sentence in the contract and a sentence in the kickoff call prevents almost all of these conversations.

Related reading

Answer scope creep from your actual contract — not a template.

Settled reads your contract and the client's request, gives you a verdict (In Scope / Out of Scope / Ambiguous), and drafts the email grounded in your specific clause.

Try it free →Read the scope creep guide