The software handover checklist: what you should own when an agency leaves

A pattern that comes up when companies approach us to take over an existing product: they own the code, technically, and still cannot ship it. The repository is there. The deployment account belongs to someone who left. The domain is registered to an agency. Nobody knows which environment variables production needs.

This is rarely malice. It is usually nobody writing down what was in whose head. But the effect is the same, and the time to prevent it is before the project starts, not at the end.

What ownership actually means

Owning software means five things, and code is only the first:

1. You have the code, with its history.
2. You can build and run it from a clean machine.
3. You can deploy it without asking anyone.
4. You control the accounts and domains it depends on.
5. You understand the decisions well enough to change it.

Miss any one and you do not have a product; you have a dependency.

The checklist

Code

• Repository is in your organisation, not a personal account, not the agency's.
• Full history, not a single squashed commit. History is documentation.
• All branches and tags, including whatever tag is currently in production.
• Design source files (Figma or equivalent) in your workspace, with fonts and licences noted.

Build and run

• A README that works on a clean machine. The test is literal: someone who has never seen the project follows it and gets the app running. If it fails at step four, it is not done.
• Dependency versions pinned, with a lockfile committed.
• .env.example listing every variable, what it does, and where to get it.
• How to run the tests, and what a passing run looks like.

Deploy

• You can deploy to production yourself, and have actually done it once before handover. Not "we could if we needed to". Done it.
• Pipeline configuration is in the repository, not clicked into a dashboard nobody can see.
• You know how to roll back, and have tried.
• Database migrations documented, including how to run them against production.

Accounts and domains

The category that causes the most pain, because each item is small and easy to forget:

• Domain registrar in your name, with renewal on a card that will not expire with someone's employment.
• DNS, with a record of what each entry is for.
• Hosting, cloud, CDN.
• App Store and Play Console under your organisation, with the signing keys and certificates. Losing an Android signing key means you can never update that app listing again.
• Email, transactional email provider, and the DNS records that authenticate it.
• Error tracking, analytics, payment provider.
• Every third-party API key, and which account it bills to.

For each: is the owner an address your company controls? Not an individual's work email. A shared or role address that survives someone leaving.

Understanding

• A short architecture note: what the pieces are and how requests flow.
• Decision records for the choices that would otherwise puzzle the next engineer. Why this database. Why not that framework. Why this odd workaround exists.
• A runbook: what breaks, what the alerts mean, what to do at 2am.
• Known issues and deliberate shortcuts, written down honestly.

Decision records are the highest-value document nobody writes. Code shows what was done. Only a written decision shows what was rejected and why, which is what stops the next team repeating a mistake you already paid for.

Test it before the relationship ends

A handover document is a claim. Verify it while the people who wrote it are still reachable.

Two exercises, both worth the afternoon:

• The clean machine test. Someone who has not worked on the project takes a fresh laptop, follows the README, and gets it running locally. Every place they get stuck is a documentation bug. Fix them then.
• The deploy test. Your team makes a trivial change, ships it to production, confirms it, and rolls it back. If any step requires the agency, the handover is incomplete.

Do these before the final payment, not after. That is not distrust; it is the only moment when everyone is still available and motivated.

Set it up at the start

Almost all of this is trivial on day one and expensive in month nine. At kickoff:

• Create accounts in your organisation and invite the agency, rather than the reverse.
• Register the domain yourself.
• Use role addresses for account ownership from the beginning.
• Agree that documentation is part of "done", not a closing task.

Set up this way, handover stops being an event. It becomes revoking some access, because everything was already yours.

What to ask before you sign

Three questions worth putting to any agency, ours included:

• Whose name will the accounts be in? Yours, from the start, is the only good answer.
• Will we be able to deploy without you? And can we prove it during the project rather than after?
• What happens if we stop working together in month three? An honest answer describes a process. A vague one is a warning.

An agency confident in its work has no reason to hold anything. If the answers are uncomfortable, that is the most useful thing you will learn in the sales conversation.