The project should outlive the person who built it.
Documentation written every two years explains the server. It does not explain why the interface looks the way it does, what was decided in March, and which option you rejected. That is exactly what goes missing at a handover.
What gets handed over
Why something was built that way sits in the history of the task where it was decided. Not in a summary written afterwards, but where the discussion happened.
Client meetings are objects of their own, with transcript and summary. What was promised sits next to the ticket that came out of it.
The technical documentation lives in the repository and travels with the code. Whoever takes the project over gets both in one go.
The new person asks the project instead of reading four years of history. The answer names its sources, so they can check whether it holds.
What it does not do
Two things that tend to get promised elsewhere.
- Nothing appears by itself. What was never recorded cannot be handed over. The effort is exactly the one you already have when you comment on tasks and capture meetings, but without it there is nothing to hand over.
- It does not replace an introduction. It shortens one, because the questions can be answered instead of hanging on a person who may already be gone.
What people ask at this point
- We are the agency. Why would we want this?
- Because it improves your offer. A client who knows they are not tied to you decides for you more easily. And when you do hand a project on, you hand it on cleanly rather than in a row.
- We are the client. How do we get at the content?
- The organisation belongs to whoever pays for it. Who runs it is your decision; access can be transferred without the data having to move.
- What about the source code?
- It lives with GitHub or GitLab and stays there. Lalabase reads it so questions about it can be answered, and does not host it.
Look at it
rather than take our word for it.
Productive in under 5 minutes. No sales loop.