What you should own when a build ends

Nothing here requires bad faith on anyone's part. Accounts get created in whoever's name was convenient, a domain is registered on a personal card during a launch weekend, deployment happens from a script on one laptop. Each is a reasonable expedient at the time, and collectively they mean the system cannot be operated without one specific supplier.

The ownership checklist

The repository, and why history matters

A zip of the final source is not a handover. What makes a codebase maintainable by someone new is the record of how it got there.

• Full commit history, not a single initial commit — it is how a new engineer answers "why is this here"
• In your organisation account, with the supplier as a collaborator who can be removed rather than as the owner
• Branch and release tags, so the version running in production is identifiable
• The pull request record, where most design discussion actually lives
• Issue history, which documents known problems and deliberate decisions not to fix them

History is also the honest audit. A repository with a single commit dated the week of handover conceals how the software was built and whether it was ever reviewed — which may be exactly why it arrived that way.

Documentation, written for the person who replaces you

Most handover documentation describes what the software does, which a new team can discover by using it. What they cannot discover is how to run it and why it is the way it is.

1. 01Run it locally — exact steps from a clean machine, tested by someone who has not done it before.
2. 02Deploy it — how a change reaches production, who can trigger it, how to roll back.
3. 03The architecture, in one page — components, what talks to what, where data lives. One diagram beats thirty pages.
4. 04Environment variables and configuration, every one, with what it does and where its value comes from.
5. 05External dependencies — every third-party service, what it is for, whose account, what breaks without it.
6. 06Operational runbook — how to restore a backup, rotate a credential, and what the alerts mean.
7. 07Decision record — the choices that would otherwise look arbitrary, with the reasoning and the alternatives rejected.

Credentials, transferred properly

A handover is also a security event: everyone who had access during the build still has it afterwards unless something changes.

• Every credential rotated at handover, so what the previous team holds no longer works
• New values placed in a store you control, not sent over chat or email
• Supplier accounts removed from every system on a named date, not "when convenient"
• Ownership of the account recovery path — recovery email and phone pointing at you, which is the one people forget
• A written list of every place a credential exists, so the next rotation is possible at all

The recovery path deserves emphasis because it silently defeats everything else. An account whose password reset goes to the supplier's mailbox is not under your control regardless of who knows the current password.

Verify it rather than accepting it

Handover is complete when you have proved it, not when a document says so. The proof is a short exercise, and it must be done while the relationship is still cooperative.

1. 01Have someone independent clone and run it, following only the written guide, with no access to the original team.
2. 02Deploy a trivial visible change — a typo fix — through your own pipeline, end to end.
3. 03Restore a backup into a scratch environment and confirm the data is intact.
4. 04Log in to every account on the list yourself, and confirm your administrator rights.
5. 05Change a DNS record and watch it propagate, which proves control of the domain.
6. 06Remove one supplier account and confirm everything still runs.

Agree this at the start, not the end

Every item above is cheap when it is a default and expensive when it is a retrofit. Creating infrastructure in your subscription on day one costs nothing; migrating it after launch is a project.

A supplier who proposes these arrangements without being asked is telling you something useful about how they work. So is one who resists them.