Here’s a question worth asking before you sign anything with a developer: if they vanished tomorrow, could you ship an update to your own app next week? For a lot of founders the honest answer is no. The code is sitting in the freelancer’s GitHub. The app is listed under the agency’s Apple developer account. The server bill goes to someone else’s credit card. Legally the founder may own the IP. In practice they can’t do anything with it.
We’ve been handed codebases in exactly this state during audits and rescue work. The code is rarely the hardest part. The slow, expensive part is getting access back. So before we write any code for a client, we ask them to own six accounts. Here they are, in plain English.
The six accounts, and why each one matters
1. Apple App Store Connect and Google Play Console
This is the one that hurts most when it goes wrong. An app on the App Store is tied to the developer account that published it. If your agency published it under their account, your listing, reviews, ratings, and install base live there. Moving an app between Apple accounts is possible, but it has conditions, takes time, and needs the current owner to cooperate. Google Play has its own transfer process with its own requirements.
What to do: Enroll as an organization in both programs using your company’s legal details. Apple’s organization enrollment needs a D-U-N-S number, which can take days to get, so start early. Then invite your developers as team members with the right roles. They can build, upload, and submit without ever owning anything.
2. The code repository
Your code should live in a GitHub, GitLab, or Bitbucket organization that you created and pay for. Your developers get added as members. A zip file at the end of the project doesn’t count as a handover. The commit history shows who changed what and why, and the next engineer will need it to understand decisions made months ago.
What to do: Create the organization yourself, make yourself the owner, and ask that all work gets pushed there from the first commit, not “once it’s ready.”
3. The cloud host
AWS, Google Cloud, Firebase, Azure, Vercel, whatever the stack uses. The account holding your database is the account holding your users’ data. If it belongs to your contractor, your customer data is on their infrastructure, under their billing, and gone if their card declines.
What to do: Open the account in your company’s name with your company’s payment method. Give developers scoped access through IAM roles or project-level permissions. Turn on billing alerts so a runaway cost shows up in your inbox and not as a surprise at the end of the month.
4. The domain
Your domain controls your website, your email, and often your app’s backend and sign-in flows. If a contractor registered it under their own registrar account, they effectively control all of that. Letting a domain expire, even by accident, can take down everything that depends on it.
What to do: Register it yourself, turn on auto-renew, and enable two-factor authentication on the registrar account. Developers rarely need registrar access. What they need is DNS changes, and you can make those or delegate them narrowly.
5. API keys and third-party services
Modern apps connect to a lot of services: payments, maps, email delivery, push notifications, SMS, and more and more often AI model providers. Each one has an account, a key, and a bill. When those accounts belong to a developer, you can end up with a payment processor whose payouts go to the wrong place, or an AI provider key tied to someone else’s usage limits and billing.
What to do: Create each service account yourself and share keys through a secrets manager or your cloud provider’s secret storage, never over chat or email. Keep a simple list of every service, who has access, and where the key is stored. If a key ever needs rotating, that list saves you a very stressful afternoon.
6. Analytics and crash reporting
Analytics tells you what your users actually do. Crash reporting tells you what’s breaking. If both sit in a contractor’s account, you lose your product history when the engagement ends: which features got used, where people dropped off, which release caused a spike in crashes. You can’t get that data back later.
What to do: Set up the analytics and crash-reporting projects under your own account and add developers as collaborators.
What going wrong usually looks like
It’s usually not malicious. The more common story goes like this: a freelancer sets things up under their own accounts because it’s faster that week. The project runs long, the relationship cools, and the freelancer moves on. They stop answering email. Nobody is holding anything hostage, but nobody is handing anything back either. The founder then pays a new team to rebuild access before any real work can start: re-publishing the app, migrating the database, re-issuing keys, and rewiring the domain.
The less common story is a dispute over an invoice where access becomes leverage. Either way, the founder is negotiating from a weak position over things they thought they already owned.
There’s also a quieter cost. When you don’t hold the accounts, you can’t independently check what was built. You can’t bring in a second opinion, run an audit, or confirm that the “almost done” backend is actually deployed anywhere.
Why we insist on this before we start
We ask every client to own all six before our first commit, and we’ll walk you through setting them up if you haven’t done it before. It usually takes an afternoon, plus waiting on Apple’s enrollment. We then work inside your accounts as invited members.
This protects you, and it also keeps us honest. If you can see every commit, every deployment, and every line on the cloud bill, you never have to take our word on progress. That’s how we’d want to be treated if we were the ones hiring. It also means that if you ever want to bring development in-house or hand it to another team, the handover is a permissions change and not a recovery project.
If you’re about to hire a studio or freelancer, send them this list and see how they respond. A good partner will say yes without hesitating. If you’re already mid-build and aren’t sure who holds what, that’s a common place to start a conversation with us. Sorting out ownership is often the first step of the audits we run, and it’s worth doing whoever ends up writing the code.