What Happens After Launch: The Maintenance Conversation Nobody Has Upfront

The most common surprise we see isn't during the build — it's three months after launch, when a client realizes nobody actually agreed on who updates the site, patches a dependency, or fixes the thing that broke after a browser update nobody controls. Launch day feels like the finish line. It's closer to the starting line for a different kind of work.

What "maintenance" actually covers

• Security patches and dependency updates — software doesn't stay still just because you stopped actively working on it, and neither do its vulnerabilities.
• Monitoring for downtime, errors, and performance regressions before a customer reports them instead of after.
• Content updates that need a developer's help — a new service page, a pricing change, a seasonal promotion — versus what a client can handle themselves through a CMS.
• Small enhancements that come up naturally once real users start using the product and surfacing friction nobody anticipated.
• Backups and the occasional test restore, so "we have backups" is actually true instead of assumed.

Why this needs to be a decision, not a default

"We'll figure it out if something breaks" is a maintenance plan, technically — it's just an expensive, reactive one, where every fix happens under time pressure instead of on a predictable schedule. Deciding upfront who owns this, and what it costs, turns an unpleasant surprise into a normal line item.

How we structure this with clients

We fold maintenance into the same upfront conversation as what the whole project actually costs — a defined monthly scope, a clear response time for anything urgent, and a monitoring setup that flags problems automatically rather than waiting for a customer to notice first. It's the unglamorous half of the project, and it's the half that determines whether the site is still working well a year from now.