DOCUMENTATION AND HANDOVER
The runbook, the decision log and a walkthrough, so the system outlives the project.
Documentation written in the last week of a project is a summary of what somebody remembers. Mine gets written while the thing is being built, because that is when the odd decisions are still fresh — why this step is a scheduled script, why that agent cannot see the mailbox, which API refused the obvious approach. Those are the notes your team needs at 2am, not a feature list.
A handover is four artefacts, not a folder of screenshots. A runbook covering start, stop, restart and restore. An inventory of every environment variable, key and credential, with where it lives and how to rotate it. A decision log holding the numbers behind each build-or-buy call. And a recorded walkthrough of the system doing its job, so the first failure is not also the first look inside.
This is included in every build I do, and it is also sold on its own — usually to somebody who inherited a working system with no notes and exactly one person who understands it. In that case I read the code, run it, map what it actually does against what you were told it does, and write the gaps down plainly. The gaps are generally the valuable part.
WHAT I DO
- Runbook — start, stop, restart, restore, plus the three failures most likely to happen first, each with the exact commands
- Architecture notes with a diagram: what runs where, which service talks to which, and what breaks when one goes down
- Secrets and environment inventory — every key, where it is stored, what it can reach, and how to rotate it without downtime
- Decision log with the numbers: what was considered, what it would have cost, and why the chosen option won
- Recorded walkthrough plus a live session with the people who will own it, taking their questions against the real system
- Access transfer checklist — accounts, domains, VM logins and billing moved into your names, with my access removed and itemised
- Stabilisation window after go-live where fixes are mine, and anything I fix gets written back into the runbook
HOW I WORK
- 01
CAPTURE
Notes, commands and decisions get written down during the build rather than reconstructed from memory afterwards.
- 02
ASSEMBLE
Those notes become the runbook, the architecture diagram, the secrets inventory and the decision log.
- 03
WALKTHROUGH
I record the system working and sit with the people who will own it, answering questions against the live thing.
- 04
TRANSFER
Accounts, keys and logins move to your names, my access is removed and listed, and the stabilisation window starts.
BEST FOR
- Any system that exactly one person currently understands
- An inherited automation with no notes that nobody dares change
- Teams who need an audit trail of what a system can reach and who holds which key
- Buyers who want a documented exit from the freelancer they hired, planned from day one
NOT THIS
- Not an ongoing managed service. Handover is the opposite of a retainer — after the stabilisation window your own people run it, and care plans are a separate conversation
- Not a course in building agents. I train your people to operate, monitor and safely change this system; teaching them to architect their own from scratch is a different job
- Not formal compliance certification. I document data flows, access and retention clearly, which helps an audit, but I am not an auditor and will not sign anything
THE PROOF
Published case studies from ai orchestration work. Each one names the client and shows what was delivered.
STRAIGHT ANSWERS
REST OF AI ORCHESTRATION
MAKE A
WISH.
Tell me what you're building. I'll tell you how loud it can get.
- /01
YOU WRITE
Tell me what you're building and what's in the way. Two lines is enough.
- /02
WE TALK
A 30-minute call, booked within 7 days. Real questions, no pitch theatre.
- /03
YOU GET A PLAN
Scope, timeline and an honest number, usually within a week.