Your contract says you own the code. Six months in, the relationship with your dev shop goes sour and you ask for a handover. Then you find out the repository sits in their GitHub organization, the app is published under their Apple developer account, the cloud bill goes to their company card, and the payment provider’s API keys were created under an engineer’s personal email. Legally the product may be yours. In practice they hold every key to it.
This is rarely malicious. Setting things up under the studio’s own accounts is simply faster at kickoff. A developer who needs a repository today creates one where they already have admin rights. The cost only shows up later, when you want to switch vendors, bring engineering in-house, or raise a round and a due-diligence reviewer asks who controls production.
The fix is cheap if you do it before the first commit and painful if you do it after launch. Here’s the checklist.
The six assets that should be in your name
An intellectual property clause covers who owns the code. It doesn’t cover who controls the accounts the code lives in and runs on. For each item below, the rule is the same: your company is the owner, and the developers are invited in with limited permissions.
1. Source code: a GitHub (or GitLab) organization
Create an organization under your company name, make yourself or a co-founder the owner, and add the dev team as members or outside collaborators. Don’t accept “we’ll transfer the repo at the end.” Transfers are technically easy, but they depend on the other side being willing and responsive at a moment when the relationship may already be strained.
2. Apple Developer Program account
Enroll as an organization, not an individual, so the app is published under your company’s name. Organization enrollment needs a D-U-N-S number, and getting one can take anywhere from a few days to a couple of weeks. That’s the main reason this step gets skipped when everyone is in a hurry. Start early. Once you’re enrolled, add your developers in App Store Connect with roles like Developer or App Manager, not Account Holder.
3. Google Play Console account
Same idea: register under your organization and invite the team with scoped permissions. Enroll in Play App Signing so Google holds the app signing key and your team only manages an upload key. If a signing key sits on a former contractor’s laptop, it can block you from shipping updates to your own app.
4. Cloud hosting and billing
AWS, Google Cloud, Firebase, Azure, whichever you use: open the account yourself and put your company card on it. Developers get their own named user accounts with access to what they need. Avoid shared root logins. The billing owner is the account owner in every way that matters. If your servers run on someone else’s card, they can be shut down over an unrelated invoice dispute.
5. Third-party API keys and secrets
Payment processors, AI model providers, email and SMS services, maps, analytics. Each one is a separate account with its own keys. Create them under a company email, generate the keys yourself or have them generated inside your account, and store them in a secrets manager you control rather than pasted into a chat thread. This matters even more for AI features, because a leaked model API key is a direct line to your bill.
6. Domain and DNS
Register the domain at a registrar account you own and turn on auto-renew with your card. Whoever controls DNS controls where your website, API, and company email actually point. Of everything on this list, it’s the easiest to lose track of and one of the hardest to get back.
The detail that quietly undoes all of it: the email address
You can do everything above and still lose control if the admin email on an account belongs to a developer. Password resets, two-factor recovery, and security alerts all go to that inbox.
Set up a handful of company-domain addresses before kickoff. A shared alias like [email protected] that forwards to you works well. Use them as the owner email everywhere. Turn on two-factor authentication with a method you control, and keep recovery codes somewhere only the company can reach. It takes about an hour and closes the most common gap we see when reviewing existing setups.
What a clean exit looks like
The point of all this is that ending an engagement becomes an admin task, not a negotiation. When you part ways with a vendor, whether it’s us or anyone else, the offboarding should look like this:
- Remove their members from the GitHub organization, App Store Connect, Play Console, and your cloud accounts.
- Rotate every API key and secret they could have seen.
- Confirm that deployment runs from pipelines in your accounts, not from someone’s local machine.
- Check that documentation for building, deploying, and configuring the app lives in your repository and not in their internal wiki.
If any step on that list needs the outgoing team’s cooperation, that’s a gap to fix now while things are going well.
It’s also a useful test when you’re comparing studios and freelancers. Ask directly: “Will you work inside accounts we own from day one?” A confident team will say yes without hesitation and may send you a setup list. If you get vague answers about “migrating everything at the end,” you’ve learned something important about the risk before paying for it.
If you’re already mid-build and the answers are uncomfortable, it’s fixable. Repositories can be transferred, apps can be moved between developer accounts through Apple’s and Google’s transfer processes, and keys can be reissued. It just takes more coordination the later you start.
How we handle it
At orithLabs we ask for access, not ownership. Our engagements run inside the client’s GitHub organization, developer accounts, and cloud billing from the first commit. That way the product we build, including apps like the ones we’ve shipped such as Crumb Count and Kompete, can always be handed off without anyone’s goodwill being involved. If you’re about to sign with any team, or you’re trying to work out what you actually control in an existing build, we’re happy to go through this checklist with you. We’ll also review how your accounts are set up as part of a code audit. No commitment needed to have that conversation.