Most clients never think about the handover until it happens. By then, it is too late to do it properly.
The handover is the moment when a WordPress project moves from the hands of the people who built it to the hands of the people who will run it. It is the transition between delivery and operation. And in most WordPress engagements, it is treated as an afterthought. A zip file. A set of login credentials. A brief walkthrough call that covers far too much ground far too quickly.
Then the developer moves on to the next project, and the client is left with a platform they do not fully understand, maintained by institutional knowledge that just walked out the door.
What most handovers actually look like
The typical WordPress handover looks something like this.
The developer sends over the WordPress admin credentials, the hosting login, and the domain registrar access. If you are lucky, they record a short Loom video walking through the dashboard. If you are very lucky, there is a basic document listing the plugins installed and what each one does.
Then they are gone. And six months later, when a plugin update breaks something, or when a new team member needs to understand how the content system works, or when a developer is brought in to make changes and needs to understand why decisions were made the way they were, there is nothing to refer to.
The platform is running. But nobody truly understands it. And every question about how it works requires either guessing, or finding and paying the original developer, or starting a discovery process that should have been documented during the build.
This is not a minor inconvenience. It is a structural problem that compounds over time and contributes directly to the rebuild cycle that costs businesses so much money.
What a proper handover actually contains
A proper handover is a body of documentation produced during the build, not assembled hastily at the end of it.
It contains an architectural overview that explains how the system is structured and why key decisions were made. It contains a component inventory that documents every reusable block and template, what it is for, how it behaves, and what its constraints are. It contains an editorial guide that explains to content managers how to use the system correctly, including what they can safely do and what they should not attempt without developer involvement.
It contains a runbook that covers routine operational tasks. How to update WordPress core safely. How to update plugins and what to check before and after. How to create a backup and restore from one. How to access logs when something goes wrong. How to handle the most common issues a non-technical operator might encounter.
It contains deployment documentation that explains the hosting environment, how staging and production are configured, how code changes are deployed, and what the process is for making changes safely.
All of this should exist before the site launches. Not because it is nice to have. Because a platform without this documentation is operationally fragile regardless of how well it was engineered.
The bus factor problem
There is a concept in software engineering called the bus factor. It refers to the number of people on a project who would need to be hit by a bus for the project to be in serious trouble. A bus factor of one means that if a single person becomes unavailable, the project is in serious trouble.
Most WordPress sites have a bus factor of one. The original developer. If they are unavailable, unreachable, or simply unwilling to help, the business is left with a platform they cannot fully operate, maintain, or extend.
Proper documentation is the solution to the bus factor problem. It transfers institutional knowledge from a person to a document. It means the platform can be understood and operated by anyone with the appropriate skills, regardless of whether the original developer is available.
This is not a nice-to-have feature of a well-built platform. It is a fundamental requirement for anything that is intended to operate reliably over time.
Why most developers do not document properly
Documentation takes time. In a fixed-price project, time spent on documentation is time not spent on features. In a time-and-materials project, clients often balk at paying for documentation because it does not feel like it produces anything visible.
The result is that documentation is consistently deprioritised, deferred, or skipped entirely. The developer knows the system intimately. The documentation feels redundant from where they are sitting. It only feels essential from where the client is sitting, six months later, when the developer is gone.
At Sproutbean, documentation is not optional and it is not an add-on. It is a core deliverable of every engagement. It is built during the project, not assembled at the end. And the handover is not complete until it is done properly.
Because a platform without documentation is not finished. It is just running.
