Introduction
A physiotherapy practice's booking site white-screening at 9:40 on a Tuesday after an overnight plugin auto-update, with no reachable backup; and a charity site with a directly-edited parent theme, an unremovable builder, and a load-bearing donation plugin abandoned in 2019 — neither of which appeared in any brief.
The site went down at nine forty on a Tuesday morning, and Teo had not touched it in eleven weeks.
It belonged to a physiotherapy practice: five practitioners, online booking, about two hundred appointments a week arriving through the site. Teo had rebuilt it the previous spring, handed it over, and moved on. There was no maintenance plan, because the practice manager had asked what it was for and Teo had not had a good answer ready.
The white screen appeared because a plugin had auto-updated overnight. The plugin handled the booking calendar. Its new version required a version of PHP the host had not yet enabled, and the interaction between the two produced a fatal error on every page — not just the booking page. The whole site.
Nobody had done anything wrong, exactly. The plugin author had shipped a reasonable update. The host was running a supported PHP version, just not the newest one. Auto-updates were on because that is the sensible default and because somebody had turned them on to be safe. The practice manager had been asleep.
By the time Teo saw the message — at ten fifteen, from a job, on a phone — the practice had been unreachable online for thirty-five minutes, was fielding calls from people who could not book, and had lost an unknown number of appointments to a competitor whose site was working.
There was no backup Teo could reach. The host had one, but the practice manager could not find the login, and the last person who had it had left. Getting to a working site took four hours, most of which was spent on the phone to a hosting support queue rather than on anything technical.
The invoice for that morning was small. The cost to the practice was not, and neither was the conversation about why the person who built the site had not been watching it.
That is the trade. Not the building. The building is the part you can do on a Sunday afternoon with music on.
There is a second thing, and it happened more slowly.
Teo's third client was a small charity whose site had been built by a volunteer in 2016, added to by two different agencies, and last substantially touched by somebody who had emigrated. The brief was "make it mobile-friendly and a bit faster."
What Teo inherited: a commercial theme three major versions behind, whose licence nobody could produce. A page builder used on some pages and not others. Thirty-four plugins, of which four were doing the same job, two had not been updated in five years, and one — genuinely load-bearing, running the donation form — had been abandoned by its author in 2019 and had no maintained equivalent. No child theme, so somebody had edited the parent theme directly, which meant updating it would erase the changes and nobody had written down what the changes were.
None of that was visible from the outside. The site looked ordinary. It looked, to the client and to Teo in the first conversation, like a small job.
Teo quoted it as a small job.
The four rules
Everything in this book comes out of four facts. They are not tips. They are the conditions the work happens under, and every checkpoint in the following thirty-seven chapters traces back to one of them.
One — you build on a stack you do not control, and it changes underneath you.
A WordPress site sits on top of WordPress core, a theme, some number of plugins, PHP, a database, a web server and a host — and every one of those is maintained by somebody else, on their schedule, for their reasons. They update independently. They deprecate things. They stop being maintained. A site that has not been touched by anybody can break because a plugin author shipped a release at two in the morning.
Which means the central mental model of most other trades — that you produce a finished thing and it stays finished — is simply wrong here. A website is not a deliverable. It is a system that decays unless somebody is maintaining it, and the whole commercial shape of this business follows from that one fact.
Two — the client has the keys and will use them.
You built it, and they have administrator access to it. They will install a plugin somebody recommended. They will paste something into a page. They will change a setting because a video said to. They will give access to a marketing agency, a relative, or somebody they met at a networking event.
None of this is unreasonable — it is their site — and all of it means the thing you built is not the thing that is running. Which is why "what changed?" is the first question of every emergency, and why the honest answer is usually "nobody knows."
Three — you inherit somebody else's decisions.
Most WordPress work, for most of your career, will be on sites you did not build. You inherit a theme you would not have chosen, a builder you cannot remove, plugins nobody can account for, and an architecture that was never designed so much as accumulated.
And here is the part that catches people: continuing an inherited architecture is a decision, and an undocumented one becomes yours. The moment you make a change and hand it back, you are the last person who touched it, and every later question comes to you.
Four — failure is public, immediate and priced by the hour.
An article that is wrong is quietly wrong. A set of books with an error carries it silently for a year. A well-run inbox produces no evidence at all. A broken website is visible to every customer simultaneously, within seconds, and it costs the business money continuously until it is fixed.
There is no quiet correction, no drafting stage, and no version of this where you fix it before anybody notices. Which means the work is not really about building — it is about making failure less likely, less severe and faster to recover from, and every practice in this book is a version of that.
What this book is built on
The economic unit is revenue per site under management — what a site returns per month across maintenance, incidents and the work that arises, against every hour it consumes. Not per project, which describes a treadmill.
The leading indicator is hours per site-month, tracked per site. It falls sharply as a site moves onto your standard stack and flattens after that. A site whose hours never fall is a site you never standardised.
The master variable is stack standardisation — the share of your maintained sites on your standard hosting, backup, security and update configuration. It is the single number that decides whether twenty sites is a business or an impossibility, because twenty sites on one stack is a routine and twenty sites on twenty stacks is twenty separate problems.
And the risk indicator is the count of maintained sites without a tested restore in the last defined period. Target zero — because a backup nobody has restored is not a backup, it is a belief, and the difference between the two only becomes apparent on the morning you need it.
How to use this book
Read Part One in order. It is the part that decides whether you should do this at all, and Chapters 5 through 8 are the four rules in full.
After that, use it as a manual. The resources are the working documents — the site audit question set, the standard stack specification, the plugin approval register, the pre-launch checklist, the restore test log, the update procedure, the profitability sheet. The prompts are at the end of every chapter, four each, and the ⚠ marks the clause that stops the specific failure that prompt is exposed to.
Every figure is blank because every figure depends on things this book cannot know. Fill them in from your own log.
And one thing to hold from the beginning: there is somebody trying to use the site while it is broken. A patient trying to book. A customer trying to pay. Somebody looking for an address at half past eight in the evening. They will never know you exist, they have no way to tell a maintained site from an unmaintained one until it fails, and they are the reason the backup gets tested.
©2026 James Henderson / https://localhandyman.work