How We Hand a Project Over

The test that defines a real handover

Our handover is complete when someone on your side has deployed a small change to production, on their own, using only the documentation we wrote. Not watched us do it — done it.

That single test finds every gap. Missing environment variables, an undocumented build step, a credential that only exists on one laptop. All of them are trivial while we are still engaged and expensive six months later.

What is in the package

• The repository, in your organisation, with full history
• A README that gets a new developer running locally in under an hour
• Architecture notes: what the main pieces are and why they are separate
• The deployment runbook — the exact steps, not a description of them
• Environment variables and where each secret lives, in your password manager
• Database schema documentation and the migration history
• Every third-party account, transferred to your ownership
• A list of the known rough edges and what we would do about each

That last item surprises people. Every system has compromises — a slow query, a duplicated concept, a workaround for a third-party quirk. Documenting them is more useful than pretending they do not exist, and your next developer will find them anyway.

The sessions

Two or three recorded working sessions, tailored to who is receiving the system.

1. For developers: a code walkthrough of the main flows, then local setup done live on their machine.
2. For whoever operates it: deployment, monitoring, backups, and what to do when something looks wrong at 9am.
3. For the business users: the admin interface and the handful of settings that matter.

All recorded, because the person who needs the third session most often joins the company two months after it happened.

Accounts and access, transferred properly

Every account created for the project ends up owned by you: hosting, domain, database, error tracking, email delivery, any API keys. We are removed as owner and kept only where you want us for support.

If a supplier still owns your DNS a year after launch, that is not a service arrangement. It is a hostage situation with an invoice attached.

We also document what each account costs and when it renews, because an unexpected annual renewal on a service nobody remembers signing up to is a bad way to learn your own infrastructure.

What we keep doing afterwards, if you want it

Most clients keep a light retainer for the first six months: dependency updates, security patches, monitoring and a small block of change hours. It is optional and it can be cancelled monthly.

If you want a clean break, take one. The whole point of the handover test is that the system does not need us. We would rather be re-hired for the next project than retained through dependency.

When the receiving team does not exist yet

Sometimes there is no internal team to hand to, because the client intends to hire one. In that case we write the documentation for a developer who has not been hired yet — more context, fewer assumptions — and we will sit in on their technical interviews if that helps.

We have also handed over to a new supplier several times. It is never awkward from our side: we answer their questions, transfer everything, and let the code speak for itself.

Frequently asked questions