The project ships, and then it belongs to someone else

For six months a rotating cast of developers has been adding keys — some on client accounts, some on agency accounts created because it was faster on the day. Nobody wrote down which was which.

On handover day you have to give the client everything they need to run the thing, remove agency access to what is theirs, and keep agency accounts out of what you are handing over. Usually this is reconstructed from a .env file and memory.

What breaks

1. Ownership is unclear per key

   A .env has names and values. It does not record which account each key came from, so separating "theirs" from "ours" means checking each one in the provider console.

2. Every developer who touched it still has a copy

   Six months of local .env files across the team, none of which are affected by anything you do on handover day.

3. The handover document is a text file with the keys in it

   It is the obvious deliverable, and it is a plaintext document containing production credentials that will live in the client’s email and yours indefinitely.

How it works here

1. The project is the unit of transfer

   Everything the build needs is in one encrypted project rather than distributed across team members’ machines, so there is a single thing to hand over and a single thing to leave.

2. Team members are removed cryptographically

   Removing the team at the end rotates the project key rather than relying on everyone to tidy up their own machine.

3. The client generates their own files

   They import the project and produce their own .env, so the deliverable is access rather than a document full of credentials.

4. Export to where it is going

   If the client runs on GitHub Actions or Google Cloud, the export targets emit the commands that put the values into that platform’s secret store directly.