When I deliver a site, a plugin, or an integration, you also get the documentation, the handoff video where useful, and the explanations that let your team maintain it without coming back to me for every change. None of that is donated hours. It’s part of the scope I quote, the same way the code is. The agency-world default — training as a separate billable line, documentation as an upsell — is a model I won’t use.
What I do
- Document what I built, in plain language your editors can read. Not just “how the code works” but “how to do the things you’ll need to do.”
- Record short handoff videos when a written guide isn’t enough. Five minutes of screen-recording often replaces a 90-minute training session.
- Link the documentation back to my public knowledge base where the topic is general. You learn from your own site’s docs and from the broader resource.
- Build admin interfaces with the assumption that the person using them isn’t a developer. Help text on every non-obvious field. Defaults that make sense.
- Leave the site in a state where your team can extend it. Custom blocks documented. Hooks named. Templates organised.
What I decline
- Black-box deliverables that require me for every change.
- Documentation as a separate paid milestone.
- Training that’s really a sales call for the next engagement.
- Engagements where the handoff is “here’s the FTP password, good luck.”
- Knowledge-transfer that exists to keep the client dependent. If you can do it without me, that’s the goal, not the failure mode.
Why this is the position
Handoff that doesn’t teach is just dependency, and dependency is a business model I’m not interested in.
There’s a long tradition in agency work of structuring engagements so the client has to come back for every change. It produces predictable revenue and predictable resentment. The clients who get good service that way don’t notice. The clients who get average service notice immediately and never refer anyone.
I’d rather build sites that don’t need me. Some of those clients come back for the next project. Some don’t, because they didn’t need to. Both are good outcomes. The first is good business; the second is good craft.
Documentation also has a side effect. If I can’t explain what I built in plain English, I probably built it wrong.
See also
- The next developer who opens my code is in a teaching moment. Teaching at the codebase level — the code itself as a teaching surface.
- Mentoring is part of how I live. Teaching outside the engagement — the same posture, different surface.
- What you owe the people still running your old code. On the long obligation a build creates — to whoever maintains it after you.
