Clients rarely leave over the launch. They leave over the month after it, when nobody agreed who updates the plugins, who restores a backup or how fast a broken form gets an answer. This post sets out the care scope we put in writing for that period, from our published sample agreements, as a 90-day checklist.
What we agree in writing before the site goes live
During a build, responsibility is clear. The day after launch, the build team moves on, the client’s team starts editing pages, and the first plugin update arrives with nobody named to apply it. The usual complaints, a slow page or a form that stops sending, are rarely hard to fix.
What turns an hour’s fix into a lost client is not knowing whether reporting it is free, who to tell, or when to expect an answer. The fix is paperwork written before launch, not heroics after it.
Our sample website project scope asks for these to be settled before launch, and our sample care scope adds the rest at onboarding. If any line is blank on your own project, that is where the first argument will come from.
- Staging access, who approves publication, and source-file handover.
- Training for the client’s editors, if it is included.
- How long defects can be reported after launch, and how qualifying issues are corrected.
- The site, stack, tools and access the care team will work with.
- The update window, and who has authority to roll back.
- Inherited defects and unsupported components, recorded at onboarding so they are not blamed on the care team later.
- The incident contact and the staffed support window.
The 90-day care checklist
The first 30 days run on a different footing from the next 60. On applicable development work, we correct defects in what we delivered that stop it meeting the agreed requirements, when they are reported within 30 calendar days of production launch. After that, routine care is a monthly cycle with a fixed scope.
| Window | What happens | What it is not |
|---|---|---|
| Launch day | Confirm backups, access and the incident contact; record any inherited defects | The end of the client’s involvement |
| Days 1 to 30 | Defects in delivered work, reported in this window, go into the correction process even if the fix lands later | New features, changed scope or third-party platform changes |
| Each month | A pre-update backup check, eligible core, theme and plugin updates, site and form checks, and a monthly summary | Daily backups or round-the-clock monitoring |
| If an update breaks something | Restore the pre-update backup, as agreed in the scope | Malware recovery or emergency support, which are scoped separately |
| Day 90 | Review what was maintenance and what was improvement; renew, rescope or hand over | An automatic renewal |
The day-90 review is the part most care arrangements skip. By then the requests have a pattern. If most of them were new pages and design changes, the client needs a small improvement budget, not a bigger maintenance plan.
What care does not cover, and why we say so up front
The standard care package in our sample scope covers one monthly maintenance cycle for one healthy, supported WordPress website. It does not imply daily backups, thirty-day retention, unused hours rolling over, round-the-clock monitoring or emergency response. New content, design changes, features, paid tools, malware recovery and emergency support are scoped when they are requested.
We also separate a response target from a guaranteed resolution time or an uptime commitment. Writing that distinction down feels unhelpful at signing. It is far less unhelpful than a client discovering it during an outage. The full sample, with the onboarding and exit terms, is on our sample agreements page.
A US county government: a site built for the client’s own team to keep current
We delivered the website design and development for a US county government: one site for many county departments, from the circuit court to parks and health and human services, organised around what residents, businesses and visitors need to do. The record names one aim directly: content structures the county’s own teams can keep current.
That shapes the care question. When the client’s departments edit their own pages, care is about the platform: updates, backups, forms and integrations such as maps. Content is theirs.
The record covers the design and the build; it does not describe an ongoing care contract, and we do not claim one. The county is not named here while its permission is confirmed.
The lesson for any agency or in-house team is to decide before launch who owns content and who owns the platform. Writing that split into the care scope removes a whole class of first-month disputes about whose job a change was.
When a care retainer is the wrong answer
Care is not always worth paying for. We would say so when:
- The site rarely changes and runs on a hosted platform that applies its own core updates. A quarterly check may be enough.
- You have an in-house developer with the time to own updates and backups. A clear runbook at handover is the better spend.
- Most of the requests are improvements rather than maintenance. That is a fixed-scope project, as our post on when a retainer is the wrong answer explains.
- The site is not healthy to begin with. Care keeps a working site working; a site with inherited defects needs fixing first.
- 1Is the site healthy to begin with?NoFix inherited defects first, then care keeps it working
- 2Does the site change often, beyond the host’s own core updates?NoA quarterly check may be enough
- 3Would updates and backups go unowned without a care team?NoIn-house developer has time: hand over a clear runbook
- 4Are most requests maintenance rather than improvements?NoThat is a fixed-scope project, not a care plan
For agencies that want to keep the client relationship and hand off the routine work, care can be delivered under your brand through our white-label WordPress service, with the scope written down in the same way.
