Post-Launch Support: What Agencies Need to Know

One of the biggest friction points between agencies and freelance developers is the "Post-Launch Limbo". Is that broken button a bug covered by warranty, or a new request?

To protect your profitability and our relationship, I structure post-launch support into three distinct buckets.

1. The Warranty (Bug Fixes)

Duration: 30 Days post-launch.

What it covers: Things that were in the scope of work but are not functioning correctly.

• Example: The contact form doesn't send emails on mobile. (Bug -> Fixed for free)
• Example: The layout breaks on Safari. (Bug -> Fixed for free)

I stand by my code. If I broke it, I fix it.

2. Maintenance (Retainer)

Duration: Ongoing (Monthly fee).

Software isn't static. WordPress updates, PHP versions change, plugins evolve.

• updating WordPress Core/Plugins
• Monitoring uptime
• Daily Backups

This keeps the "engine" running but does not cover design changes.

3. Feature Requests (Billable)

Duration: Ad-hoc.

Clients often disguise feature requests as "fixes".

• Client says: "The popup isn't showing up." (When there was never a popup in the design).
• My response: That is a new feature.

For these, I offer Pre-paid Hourly Banks. The agency buys 10 hours of my time, and we use it for these small tweaks. It eliminates the need to quote every 15-minute task.

Why definitions matter

By defining these upfront, you can confidently tell your client: "Yes, we can change the header color, that falls under your maintenance package" or "That adds new functionality, we'll need to quote it."