Here’s a call we don’t like getting: a founder has paid a developer or agency for a year and the relationship has gone bad. When they ask for “the app,” they get a zip file. There’s no repository history and no login to the App Store listing, and the production server is billed to a card that isn’t theirs. They paid for the software, but they don’t control it.
If you’re not sure you own your app, you can find out in about an hour. You don’t need to read code or accuse anyone of anything. You need to check who holds the keys to five accounts. Do it now, while things with your vendor are going fine, because that’s when fixing it is cheap and easy.
Why this only comes up when something goes wrong
Most ownership problems aren’t malicious. A freelancer sets up the Apple developer account under their own name because your company didn’t have a D-U-N-S number yet and the launch was close. An agency puts your backend on its own cloud account because it already has billing set up there. Each shortcut makes sense on the day someone takes it. Nobody writes them down, and none of it gets moved over later.
Then the contract ends, the freelancer takes a full-time job, or you want a second opinion from another team. Now every one of those shortcuts is a dependency on someone who has no obligation to answer your emails quickly.
A contract with an IP assignment clause helps. It gives you the legal right to the work. It doesn’t give you the passwords. You can have the paperwork on your side and still spend weeks getting a store listing transferred.
The five accounts that decide whether you own your app
For each one, the question is the same: is the owner or admin of this account a person or entity you control? Your vendor should be a member or collaborator. They shouldn’t be the owner.
1. The code repository
Your code should live in a GitHub, GitLab, or Bitbucket organization that your company owns, with your developers invited as members. A zip file of source code isn’t the same thing. The repository’s history shows who changed what and why, and the next team will depend on it when they debug something at 2am.
Check that you can log in, see the full commit history, and that it includes everything: the mobile app, the backend, the admin dashboard, and any infrastructure or CI/CD configuration. A backend that only exists on the vendor’s machines is a common gap.
2. App Store and Google Play developer accounts
This one hurts most when it goes wrong. Your app’s store listing, reviews, download history, and bundle identifier all belong to whichever developer account published it. If that’s your freelancer’s personal account, the listing is legally and practically theirs until someone transfers it. Both Apple and Google support app transfers, but both have conditions, and the transfer needs the current account holder to cooperate.
On Android, also ask about the app signing key. If the app uses Play App Signing, Google holds the key and a lost upload key can be reset. If it’s an older setup where the developer kept the signing key themselves and that file is lost, you can’t publish updates to that listing at all. That’s worth a two-minute question.
3. Cloud hosting
AWS, Google Cloud, Firebase, Azure, a VPS provider: whatever runs your backend and database should be on an account where your company holds the root or owner login and the billing. Vendors should get scoped access through the platform’s user and role system, not the master password.
A practical test: if your card stopped paying the hosting bill tomorrow, whose inbox would get the warning? If the answer isn’t yours, your production data is sitting on someone else’s account.
4. The domain name
Look up who the registrant is and which registrar account the domain sits in. Domains are often bought “quickly” by whoever set up the website. Your domain controls your website, your email, and often your app’s API endpoints and login links. Losing it takes all of those down at once.
5. Third-party API keys and services
This one is the hardest to check because it’s spread out. Modern apps depend on a long list of services: payments (Stripe, Razorpay), push notifications (Apple push keys, Firebase Cloud Messaging), maps, email and SMS, analytics, crash reporting, and more and more often LLM providers for AI features. Each one is an account with its own owner and its own billing.
Ask your developer for a plain list: service name, what it does in the app, whose account it’s on. If the payment processor is on the vendor’s account, the money may be flowing through someone else’s merchant relationship. That’s an application security and compliance problem as well as an ownership one. With AI keys, whoever holds the key can see usage logs and, depending on the setup, the prompts themselves.
How to fix gaps without starting a fight
If you find gaps, and most founders find at least one, treat it as routine cleanup, not an accusation. A reasonable developer won’t be offended by any of these steps:
- Create the accounts in your company’s name first. A GitHub organization, an Apple and Google developer account (budget time for Apple’s organization verification), a cloud account with your billing, and a registrar account.
- Invite your vendor in with the access they need. Admin rights on the repository are fine. Owning the organization isn’t.
- Request transfers one at a time, starting with the store listings and the domain, since those take longest and have the most outside dependencies.
- Rotate API keys once the transfer is done, so the old credentials stop working.
- Keep a one-page access register listing every account, its owner, and who has access. Update it whenever someone joins or leaves.
If your vendor resists any of this, especially moving the repository or the store accounts, take that seriously. It tells you something about the relationship, and it’s much better to learn it now than when you’re trying to leave.
At orithLabs we set this up from the first week of a project: accounts in the client’s name, our engineers invited as collaborators, and a written list of every service the app depends on. When we do a code audit or help unstick someone else’s stalled build, the ownership check is one of the first things we look at, because nothing else can be fixed safely until it’s sorted out. If you’re not sure where your app stands, we’re happy to go through the five accounts with you and tell you plainly what we find.