By Mehdi HassanWhat post-launch support should a web design agency provide?
A web design agency should provide a defined warranty period after launch, in which it fixes defects in its own work for free, plus a clear handover and a path to paid support for anything new. Launch is when real users start finding the edge cases, so support shouldn't end the moment the site goes live.
Post-launch support is one of the clauses buyers skim, because launch feels like the finish line. In practice, the first weeks after launch are when forms get real submissions, editors publish their first posts and visitors arrive on devices no one tested. Our web design contract checklist covers how the warranty fits with handover and ownership; this guide focuses on what good support after launch looks like.
Two kinds of support get mixed up. The warranty covers the agency's mistakes. Ongoing support covers your new needs. Keeping them separate is what makes both fair.
What does a website warranty period cover?
A website warranty period covers defects: things that don't work as specified or don't match approved designs. It doesn't cover new features, new pages, content updates or changes caused by third-party services or edits made after handover.
Issue after launch | Covered by warranty? | Why |
|---|---|---|
Form doesn't send submissions | Yes | Specified feature that doesn't work |
Layout breaks on a supported browser | Yes | Defect in the build |
Page doesn't match approved design | Yes | Deviation from agreed work |
CMS field missing for an agreed template | Yes | Incomplete deliverable |
New page or section | No | New scope, quote it separately |
Copy or image changes | No | Content update, not a defect |
Third-party tool changes its API | Usually no | Outside the agency's control |
Issue caused by edits after handover | No | Change made by someone else |
The grey areas are worth agreeing in advance. A layout that breaks because an editor pasted a very long headline might be a defect, if the template should have handled it, or a content issue, if the guidelines covered it. A good contract defines supported browsers and devices, so you're not debating whether an old browser counts.
How long should a website warranty period be?
A website warranty period should be long enough to cover a full cycle of real use: forms receiving submissions, your team publishing through the CMS, and traffic arriving from every device you support. For most marketing sites that means weeks rather than days, and longer for complex builds with integrations.
There's no universal number, so judge the window against what needs to happen inside it. If your team won't publish its first blog post until a month after launch, a two-week warranty ends before the CMS is really tested. If the site has a booking integration that only runs at month-end, the window should include a month-end. Ask the agency to explain its window in those terms.
Also check response times inside the window. A warranty that promises fixes but doesn't say when is weaker than it looks. A fair clause separates urgent issues, like a broken checkout or contact form, from minor ones, and gives a response time for each. The website requirements checklist is a good place to list supported browsers and integrations before the project, so the warranty has something to measure against.
How do you get the most from post-launch support?
Get the most from post-launch support by testing the site actively during the warranty window, rather than waiting for problems to appear. A short structured check in the first days after launch finds most defects while they're still covered.
Test every form and integration
Submit each form, book a test meeting, sign up for the newsletter, and confirm the data arrives where it should.
Publish through the CMS
Have the people who'll run the site create, edit and publish a real piece of content on every template.
Check devices and browsers
Go through key pages on the phones and browsers your visitors use, using the supported list in the contract.
Check search basics
Confirm the sitemap, redirects, metadata and analytics are working, especially if old URLs changed.
Log issues in one list
Report each defect once, with a screenshot and steps, and track it to closed before the window ends.
If the launch included a migration, search checks deserve extra time. Redirect gaps and missing metadata don't look like bugs, but they show up later as lost traffic. Our guides to a traffic drop after a website migration and website migration recovery cover what to check and how to fix it.
When should post-launch support become a retainer?
Post-launch support should become a retainer when the work you need is new rather than corrective: new pages, landing pages for campaigns, product updates, experiments and regular design changes. A warranty fixes what was built; a retainer builds what comes next.
The signal is usually a growing list of requests that aren't defects. You want a page for a new feature, a pricing change, a campaign landing page, and better onboarding screens. Handling each as a separate quote is slow and often more expensive, because every request needs scoping and scheduling. A retainer gives you a team with context and a monthly price you can plan around.
If your needs are mostly maintenance, a care plan may be enough, and a retainer would be more than you need. Our guide to who updates the website after launch helps you decide who owns what, and website cost per month shows the running costs to budget for. Before signing anything ongoing, read the terms in our design retainer agreement checklist.
What should you check in the support clause before signing?
Before signing, check that the support clause defines the warranty window and when it starts, what counts as a defect, supported browsers and devices, response times, how issues are reported, and the rate or plan for work outside the warranty.
- Start date. The window should start at launch, not when the agency delivers files to staging.
- Defect definition. Tied to the agreed scope and approved designs.
- Supported devices and browsers. Listed, so there's no argument later.
- Response times. Separate for urgent and minor issues.
- After the window. How paid support works, and at what price.
- Access. Who keeps admin access during and after support.
For example, suppose a form bug appears after the window ends
For example, suppose a contact form starts failing two months after launch. If the cause is a defect in the original build that only appears with a certain input, a fair agency will often fix it anyway, because it's their mistake. If the cause is the form provider changing its service, it's new work.
A good support clause doesn't need to predict every case. It needs a clear default, such as defects in the original build reported after the window are quoted at a set rate, so both sides know where to start the conversation.
Support terms are also one of the clearest ways to compare an agency with an AI site builder or a DIY approach. With a builder, support is the platform's help center. With an agency, it's a named team. Our comparison of an AI website builder vs an agency covers that trade-off in more depth.
