The short answer
Five things: written documentation, a named owner on your side who has already changed the system themselves, training for everyone who touches it, no credentials held by the consultant, and a written list of what will break and what to do about it. If you cannot change the system without them, the job is not finished.
The checklist
1. Written documentation of how it works and why. Not just the steps — the reasoning. The next person to change this system needs to know why a decision was made before they can safely reverse it.
2. A named owner who has already changed the system. Not been shown. Not been told they own it. Has actually made a change, while the person who built it was still there to help when it went wrong. A named owner who has never touched the thing is a name on a document.
3. Training for the people who use it. On the real system, with real work, not a demo. Everyone who touches the process, not only the owner.
4. No credentials held by the consultant. Everything runs under accounts you own. You can rotate every key the day the engagement ends without breaking anything.
5. A written list of what will break. What is most likely to fail, what it will look like when it does, and what to do about it. Every system has these. Only some handovers admit them.
The test that matters
Can your team change the system without calling anyone?
Not fix it when it breaks — change it. Add a step, alter a rule, adjust a threshold. That is the difference between owning a system and renting one, and it is the only measure of handover that cannot be faked in a document.
Try it before the engagement ends, while there is still someone there to ask. A handover you test in month four is a handover you find out was incomplete in month four.
Why the incentives run against you
There is a version of this business that is much easier to run: build something the client cannot maintain, hold the credentials, and the monthly invoice never stops. It is a common model and it is very profitable.
It also produces worse systems. When the people using a process cannot change it, they stop reporting what is wrong with it, and the system drifts away from the work it was built for. What you end up paying a retainer to preserve is something that no longer quite matches the job.
So ask early, while you still have leverage: what does handover include, and what do I need you for afterwards? An answer that amounts to “ongoing support” is worth pressing on.
What a retainer should and should not cover
Reasonable: new work. A new process, a significant extension, a rebuild after you change a core system.
Not reasonable: keeping the existing thing running. If a finished system needs its builder on a monthly fee to stay alive, it was either built wrong or built that way on purpose. Neither is your problem to fund.
Last updated 18 August 2026 by Hugo, founder of Hugo Signal.
Bring me the process that wastes the most time.
A first call takes thirty minutes. You will leave it knowing whether automation is worth doing at all in your case.