Before a developer or agency finishes a project, a business should hold owner-level access, in accounts registered to the business and billed to its own card, for its domain registrar and DNS, code repository, hosting and database, app store developer accounts, payment provider, email sending service, analytics and Search Console, and every third-party API key — plus written instructions for deploying, rolling back and restoring a backup. Shark Labs sets projects up this way from the first commit, so a handover is a permissions change rather than a migration.
Most software lock-in isn't anybody's plan. A freelancer registers the domain on their own account because it was quicker. An agency publishes the app under its developer account because yours wasn't set up yet. Two years later the relationship ends, perfectly amicably, and it turns out that the business doesn't technically own its own website.
This is the list we would want a client of ours to run against us. It is written for the person paying, not the developer leaving, and it is ordered by how much damage each item does when it's missing.
The rule underneath every item
Owning a system
Holding the top-level role on the account — Owner, Account Holder, or Registrant, depending on the service — in an account registered to the business, logged into with a company email address, and billed to a company card. Being added as an admin or collaborator on someone else's account is access, not ownership: whoever holds the account can remove you.
The pattern that works is the reverse of the common one. The business creates every account and invites the developer in. The developer never creates an account the business is later invited into.
1. Domain and DNS — check this first
The domain is the root of everything else. Whoever controls it controls your email, and whoever controls your email can reset the password on every other account on this list. If you only check one thing today, check this.
- The registrar account is yours, and the registrant contact on the domain is the business, not the developer.
- Auto-renew is on, billed to your card. An expired domain can be registered by someone else.
- You know where DNS is hosted. It is often not the registrar — Cloudflare, Vercel or the old host — and that account needs the same treatment.
- Do it before the relationship ends, not after. Under ICANN's transfer policy, a change of registrant normally triggers a 60-day lock on moving the domain to another registrar, unless the registrar offers an opt-out and it is used before the change. That's a nuisance with a cooperative developer and a real problem with an absent one.
2. The code
- The repository lives in a GitHub (or GitLab) organisation you own, with the developer as a member. Transferring a repository keeps its history and issues, so if it's currently on their account, ask for a transfer rather than a zip file.
- It builds from a clean checkout. Ask someone else to clone it and follow the README. If setup depends on a file that only exists on the developer's laptop, you don't have the code yet.
- Every environment variable is listed — name, what it's for, and which account issued it. Not the values in a document; the list, so you know what to rotate.
3. Hosting, database and backups
- The hosting project sits in your team, not the developer's — Vercel, Netlify, AWS, wherever. On Vercel, note that the free Hobby plan is for non-commercial personal use only; a business site needs Pro.
- You are the owner of the database organisation — Supabase, Neon, RDS — not a member of the developer's.
- Backups exist, and someone has restored one. A backup that has never been restored is a hypothesis. Ask for the date of the last tested restore.
- File storage is included. Uploaded images and documents often live in a separate bucket that nobody remembers until it's gone.
4. App store accounts
This is the item that's slowest to fix after the fact, so it is worth getting right before the first release.
- Publish under the business's own developer accounts. On Apple, enrol as an organisation, which needs a legal entity and a D-U-N-S number; Dun & Bradstreet can take up to five business days to issue one, so start early. Google Play organisation accounts ask for one too.
- If the app is already under someone else's account, it can be moved. Apple's app transfer is started by the sending account's Account Holder and accepted by yours, and the app keeps its ratings, reviews and bundle ID. Google Play transfers go through a request to Play support. Both require the app to be in good standing, and both are much easier while the developer is still answering emails.
- You hold the signing keys. On Android, make sure the app uses Play App Signing, so Google holds the key rather than one developer's machine.
5. Money
- The payment provider account — Stripe, Razorpay, PayPal — is in the business's legal name, paying out to the business's bank account. A payment account is tied to a legal entity and its verification; it isn't something a developer can simply hand over later.
- Every subscription the product depends on is billed to you. Hosting, database, email sending, error tracking, maps, AI APIs. A developer's card expiring is a surprisingly common cause of outages.
6. Email that actually arrives
- The sending service account is yours — Resend, Postmark, SendGrid, SES — and its domain verification records are in your DNS.
- SPF, DKIM and DMARC are set on your sending domain. Google's rules for anyone sending more than 5,000 messages a day to Gmail addresses require SPF and DKIM, a published DMARC policy, a From address that aligns with them, and one-click unsubscribe on marketing mail. Below that volume they're still what keeps password-reset emails out of spam.
7. Analytics and search
- The Google Analytics property is in an account you own. If it was created in the agency's account, GA4 can move a property between accounts, keeping its history, provided someone is an administrator on both — which is another thing to do while they still are.
- You are a verified owner in Google Search Console, not just a user. Search Console distinguishes verified and delegated owners: a verified owner can remove delegated ones, and a property with no verified owner left is a property nobody can manage. Verify yourself with your own token.
- Same for Bing Webmaster Tools, Google Business Profile and any ad accounts. Ad accounts in particular often carry your conversion history; losing them means starting your campaign learning from zero.
8. Licences
Paid fonts, stock photography, premium themes and plugins, paid UI kits and icon sets are all licensed to someone. If that someone is the developer, you may be using assets you have no right to once they stop working for you. Ask for a list of every paid asset and who the licensee is, and get the licences reissued to the business where the terms allow it.
9. The documentation
Not a forty-page architecture document nobody will read. Five short answers, written down:
- 01How do we deploy a change? Step by step, including who has to approve it.
- 02How do we roll back a bad deploy?
- 03How do we restore the database from a backup?
- 04Where do errors and alerts go, and who gets them?
- 05What is known to be broken, fragile or overdue? The honest list. Every system has one.
The copy-paste version
- 01Domain registrar account and registrant contact in the business's name; auto-renew on our card
- 02DNS host account owned by us
- 03Code repository in our organisation; builds from a clean checkout
- 04List of every environment variable and which account issued it
- 05Hosting team and database organisation owned by us, on a plan that allows commercial use
- 06Last tested backup restore, with a date
- 07Apple and Google developer accounts in the business's name; apps published there
- 08Android app on Play App Signing
- 09Payment provider account in the business's legal name
- 10Every product subscription billed to our card
- 11Email sending account owned by us; SPF, DKIM and DMARC set
- 12Analytics property in our account; we are a verified owner in Search Console
- 13List of paid assets and their licensee
- 14Written answers: deploy, roll back, restore, alerts, known problems
- 15Developer's access reduced or removed, and every shared secret rotated
If you're already locked out
Work in the order of the list, starting with the domain. Registrars have a process for proving you are the registrant, usually with business registration documents, and once you control the domain you control the email addresses that every other account's password reset goes to. Most of the rest of the list can be recovered from there, one account at a time. The app store accounts and payment accounts are the hardest; contact their support teams with your business documents early, because those processes are slow.
How we set it up
Every Shark Labs project runs on accounts the client owns from the first commit: their repository, their hosting, their database, their developer accounts, their card. We are invited in, and removing us is a permissions change. It costs us nothing to work this way and it removes the one reason a client might stay with us that has nothing to do with the work.
It's also why we can publish a retainer with thirty days' notice and no minimum term. If staying with us is ever easier than leaving for reasons other than the work, something has gone wrong. What a retainer actually costs covers the other half of that decision.