Everything you'd need to run the app without them: the full code repository with its history, owner-level control of every account the app uses, a list of every setting and secret, written notes on how to build, deploy and fix it, and a signed IP assignment if they weren't your employee. Get it before they leave, then test it: someone else should be able to deploy the app using only what was handed over.
What's the problem
A developer or agency is finishing up, or has already gone, and you're not sure what you should have received. Most handovers fail the same way: everything looks fine until the first time something breaks and the one person who knew how to fix it is gone.
Why it happens
- Access isn't ownership. Being added as a collaborator to someone else's account isn't the same as owning it. If they close the account, you lose it.
- Settings live outside the code. Passwords, keys and addresses are kept in the hosting dashboard or a local file, deliberately out of the code. A repository on its own won't run.
- The knowledge is in their head. How to deploy, which service does what, and why that strange workaround exists.
How to fix it
Use this as the checklist. Tick each item only when you've confirmed it yourself.
- Code: the repository, with full history, transferred to an account or organisation you own, with at least two people from your side as owners.
- Domain: registered in your name or your business's, with the registrar login in your control.
- Hosting and cloud: the accounts in your name and on your card, with owner access.
- Database: access, a recent backup, and how to restore it.
- Outside services: email sending, payments, maps, analytics, storage and any paid APIs, with owner access to each.
- App stores: the apps published under your developer account, not theirs.
- Settings and secrets: a complete list of environment variables and what each is for. Replace any secret they knew after handover.
- Documentation: how to run it locally, how to deploy, how it fits together, known problems, and what's unfinished.
- Ownership: a signed written assignment of copyright, if they were a contractor rather than your employee.
- Proof it works: someone other than the departing developer deploys from the notes alone.
Australian law
If they were a contractor, the copyright in what they wrote stays with them unless it's assigned to you. Section 196(3) of the Copyright Act 1968 (Cth) requires an assignment to be in writing and signed. Put it on the checklist. See who owns the code my developer wrote.
General information, not legal advice.
When to call Preventionlabs
When the handover never happened, or happened and the app still won't run. This checklist is also how every resurrection ends: all code in a repository you own or control, control of every account we set up, plain-language documentation on how it fits together and how to run, deploy and scale it, and our own access removed. Then we recommend you rotate any credentials you shared with us.
Submit your project for a free assessmentFree assessment. $10,000 AUD flat to get it live, only if we take it on and you go ahead.
Sources
- GitHub: Transferring a repositoryofficial docs
When you transfer a repository to a new owner, they can immediately administer the repository's contents, issues, pull requests, releases, projects, and settings.
- GitHub: Roles in an organizationofficial docs
Organization owners have complete administrative access to your organization. This role should be limited, but to no less than two people, in your organization.
- The Twelve-Factor App: III. Configengineering methodology
An app’s config is everything that is likely to vary between deploys (staging, production, developer environments, etc).
- Copyright Act 1968 (Cth): Section 196(3): assignments must be in writinglegislation, compilation No. 65
An assignment of copyright (whether total or partial) does not have effect unless it is in writing signed by or on behalf of the assignor.