Handover is a feature, not a phase

A lot of agency work leaves a client with software they cannot change. The code runs, but the knowledge left with the people who wrote it. Six months later a small change needs a new contract, because nobody in house can safely touch the codebase.

We treat handover as something you build throughout, not a phase at the end.

Handover during, not after

• Client engineers are in the codebase from the first week, reviewing pull requests and pairing on real work
• Architecture decisions are written down as short records, at the time, with the context and the alternatives
• Runbooks for the boring but critical tasks, deploy, rollback, restore, rotate a secret, are written the first time we do the task
• The system is documented where engineers look, in the repository, not in a wiki nobody opens

The codebase is the main artifact

We optimise for a stranger reading the code in a year: conventional structure, no clever abstractions that only make sense if you were in the room, tests that describe intent, and a README that gets someone running locally in under fifteen minutes.

What we leave

• A codebase your engineers have already been working in
• Decision records and runbooks written in context
• A short recorded walkthrough of the architecture and the sharp edges
• An agreed support window that tapers, so there is a safety net without a dependency

The goal is that the day we leave is uneventful, because nothing about how the software is maintained changes.