The team that benefits from the prototype owns it, through one named person. When the builder moves on, hand over the repository, credentials, deployment access and a short runbook to a successor, or retire the prototype. If nobody accepts ownership, that is your answer: shut it down.
Why ownership breaks
Prototypes are built by one enthusiastic person, often outside normal planning. They hold the keys, know where it runs and remember why it works. When they change teams or leave, the knowledge goes with them while the app keeps running.
AI tools make this worse because the code may never have been fully read by anyone, including its author.
What a handover includes
| Item | What to transfer |
|---|---|
| Source | Repository admin rights, not just read access |
| Hosting | Deployment accounts and who pays for them |
| Credentials | Rotate every key; do not pass old ones along |
| Data | What it stores and where, with a retention note |
| Dependencies | Lockfile, update approach and known issues |
| Runbook | How to deploy, roll back and turn it off |
| Context | What it is for and who uses it |
Rotate, do not hand over secrets
A successor should get new credentials, not the departing person's. Revoke the old ones when the handover completes. This also tests that the new owner can actually deploy.
The read-through session
Have the builder walk the successor through the code for an hour. Focus on the parts the AI wrote that the builder did not fully check: authentication, data access and anything that calls external services. Note the answers in the README.
What to check in the first week
After the handover, the new owner should deploy once from scratch, confirm alerts reach them, run the dependency scan and read the list of accepted risks. A first deploy by the new owner is the clearest proof that the handover worked, because it surfaces any step that only the builder knew.
If no one wants it
That is useful information. Options:
- Retire it. Take down the deployment, revoke keys, delete the data, archive the repository.
- Archive it read-only with a note that it is unsupported, if the code has value as reference.
- Escalate to the team that benefits and ask for a decision with a date.
What you should not do is leave it running because retiring feels like paperwork.
Prevent the problem
- Record an owner and a backup owner in the repository from day one.
- Include prototype ownership in your offboarding checklist: list every repository, key and deployment the person controls.
- Review the owner list monthly.
Where Safeguard fits
Safeguard's asset discovery and agent identity capabilities can help you see what is running and under whose identity, which is useful when you build an offboarding checklist. Dependency scanning keeps the handover list of known issues current. Try the free scan at gold.safeguard.sh/scan.
Quick check
Is a team alias enough as an owner?
Not on its own. Name a person, with a backup, so there is someone to ask.
What if the builder left without a handover?
Rotate every key tied to them, find where it runs, and decide quickly whether to adopt or retire it. Do not leave it running unreviewed.
Last reviewed: 19 October 2026.
