Maintenance retainers that pay again.
Updates proved page by page. Small requests from clients handled, with a record of each one. Your team reviews the proof instead of clicking round every site.
For web agencies with sites on retainer. Set up for you, not handed over.
Larch client · Monthly updates
Project agent · WordPress
Update WordPress core and the plugins on the Larch client site, and prove nothing broke.
PLAN
- Take a database dump and check it has content.
- Update core, then the plugins, and read the new version back from the file.
- Load every key page three times before and after, and compare status and size.
RISK: low · update only, no content change
UNDO: restore the dump and the files
Where retainer hours go.
A retainer is a list of small jobs that repeat. Each one is easy. Together they fill the month, and your client sees none of it.
Updates, site by site
Core, plugin and theme updates mean clicking round the pages afterwards, on every site. It is careful work, and it takes the longest.
Small requests
A new opening time, a swapped image, a price on a page. Each one is quick to do and slow to fit between bigger jobs.
Proof nobody can see
When a client asks what you did this month, the answer sits in your head and a ticket list. A retainer you cannot show is hard to defend.
The same four steps on every Orchestrator job.
The Orchestrator is the agent that does the work. You stay in charge of the plan.
Brief it
Name the client and the job in plain words. The agent reads that client's history and the WordPress playbook first.
Approve the plan
It writes a short numbered plan with the risk and the way back. You approve it, change it or reject it.
It does the work
It takes a backup, runs the update and reads the new version back from the file.
You get the proof
Screenshots, plus status and page size for every page it checked, before and after. Anything odd is flagged with the reason.
What you can put on a retainer.
Each of these is work you already do. The difference is that every one comes with a record.
Updates proved page by page.
After a core or plugin update the agent checks the pages, not just the version number. It loads each page three times before and three times after, because security tokens change the bytes on every load. Then it compares status and size for every URL.
- Screenshots before and after
- Status and page size for every page checked
- A 200 alone is not proof, so it looks for the broken page behind it
Hale client · Core update
Status and size, 3 loads each
- Home · 200 before, 200 after, same size
- Classes · 200 before, 200 after, same size
- Contact · 200 before, 200 after, same size
- Login · 200 before, 200 after, 2,637 bytes more, expected from core
Screenshots saved for before and after
Small changes, handled where the client asks.
Give each client a workspace for their own project. They sign in with Google, ask in plain words and watch the job run. You choose whether they can ask or only look. They never see another client, or your own dashboard.
- Only the email addresses you list can sign in
- One project, nothing else
- Requests queue up, so two people never collide on one site
Northgate client · Your website
Signed in as the client
Please change Saturday opening to 9am on the contact page.
PLAN
- Change the Saturday hours on the contact page.
- Check the page on desktop and phone.
Or, on a site with Webgentic for sites, the owner asks directly.
On a site with Webgentic for sites, the owner types the request on their own site. The agent writes a plan, the change appears on the page as it is made, and Stop cancels the job on the server. Every change is saved with a plain-English note, so any earlier version restores in one click.
- A plan first, then the change shown as it happens
- A full history, written in plain English
- One-click restore of any earlier version
Know the difference. There is no approval step on Webgentic for sites. A change is live as soon as it is made, so restore is the safety net. For work you want to approve first, use the Orchestrator. See Webgentic for sites
Hale client · History
Webgentic for sites
- Changed the Saturday classes price on the classes pageRestore
- Moved the booking button above the timetableRestore
- Replaced the hero photo on the home pageRestore
PHP and security patching, on the same retainer.
Keeping a site current is more than plugins. The server underneath needs patching too, and a version number does not prove it worked.
Patch the server, then prove every site on it.
The agent checks what each site actually serves after a server or security update, not what the package manager reports. See security patching and upgrades
Pricing the retainer.
We do not set your prices, and we will not guess a figure for you. This is how we would think about it.
The Orchestrator is priced on a call, because setup depends on how many clients and platforms you bring. See pricing
Sell the outcome, not the hours
A client does not care how long an update took. They care that the site still works. Price the retainer on that, and keep the proof as the reason it is worth paying.
Turn hours into checks you can show
Each job ends with a written validation and a cost. You can see what a month of upkeep really takes before you set the fee.
Bill what has a record
When every request is logged with its proof, small changes stop being favours. You can include them in the fee or charge for them, and either is easy to explain.
A real job: a core security release across about 50 sites.
A WordPress security release landed and about 50 sites needed it. The updates were clean. The time went on reading the results correctly.
What the proof showed.
For the Hale client's estate, the agent recorded status and page size for each URL before and after, loading every page three times first. A few things looked like faults, and a few looked like success.
- Exactly 2,637 extra bytes on all 8 login pages. That is the core change itself, so it was expected
- One Divi site returned a single HTTP 500, then 200s, while it rebuilt its cache
- One homepage shrank by 6,026 bytes for good, as its CSS moved to an external file
Example based on a real job, details changed.
Hale client · Core security release
What the checks caught
- Login pages · the same 2,637 bytes more on every one. Core change.
- Divi site · one 500, then 200s. Cache rebuilding.
- Homepage · 6,026 bytes smaller. CSS moved to a file.
Why it was not just a green tick.
A version number or a 200 would have passed all of it. The agent read the version back from the file, because one update printed an error, exited cleanly and changed nothing. It also checked that each database dump held real content. One stub of 843 bytes had passed a size check.
- A WordPress error page can still return 200
- A backup counts only once it has content
- Every expected difference is written down with its reason
Larch client · Checks
Complete- Version read back from the file
- Database dump holds real content
- Each page loaded 3 times, before and after
- Every difference explained
Platforms it covers.
Counted from our own delivery records, 29 October 2026. Each platform has its own playbook, corrected every night.
| Platform | What we have done on it | Page |
|---|---|---|
| WordPress | 41 client projects, from Divi to Elementor, plus WooCommerce shops. | See WordPress |
| Magento and Hyvä | 24 client projects: Page Builder, extensions and big catalogues. | See Magento |
| Drupal | 11 client projects: entities, views, config sync and upgrades. | See Drupal |
| Servers | Linux, cPanel, PHP upgrades, certificates and patches. | See servers |
Questions agencies ask about maintenance
Does it replace my developers?
No. It takes the repetitive upkeep off them and turns them into reviewers of more work. In the Orchestrator, a person on your team approves every plan.
Can an update break a client site?
Yes, any update can. That is why the plan states the risk and the way back, and why every page is checked before and after. If something differs, you see it with the reason, and you can restore.
Do my clients need to see any of this?
No, not unless you want them to. A client workspace is optional. You choose whether a client can ask for changes or only watch.
What happens when a client asks for a small change?
Two ways. With the Orchestrator, the client asks in their workspace and a person on your team approves the plan first. With Webgentic for sites, the site owner asks on the site itself, there is no approval step, and every change is saved with a note so any earlier version restores in one click.
Which platforms does it handle?
Mostly WordPress, Magento and Drupal, plus servers and plain PHP sites. Shopify and Craft CMS work is light so far. The platform pages show how deep each one goes.
How much does it cost?
The Orchestrator is priced on a call, because setup depends on how many clients and platforms you bring. Join the waiting list and we will be in touch.
Something else on your mind?
Ask us directly and a developer will reply.
Ask a question
Put your retainers on firmer ground.
Join the waiting list. When your place comes up, we will show you the Orchestrator proving an update on one of your own sites.