TL;DR: When a developer or agency builds software for you, the code is only one of the things you need to own. You also need the accounts it runs on: the code repository, the domain and DNS, the cloud and hosting accounts, the Apple and Google developer accounts, the API keys for paid services, the phone numbers and messaging registrations, and the CRM or automation workspace. The rule I follow with every client is simple: the business creates and pays for every account in its own name, and invites the developer as a user. If the developer disappears tomorrow, you should lose a person, not your product.
I have been on both sides of this. As a freelancer and later as a fractional CTO for startups in the US and Italy, I have been the developer invited into a client's accounts. I have also been the person who inherits a product and has to work out who controls what, which is the first thing I check in the first week with an inherited codebase. The setups that go smoothly look the same every time, and the ones that go badly also look the same every time.
Why ownership is the problem nobody plans for
At the start of a project, everyone is focused on what the software should do. Accounts get created by whoever needs them first, usually the developer, usually on their own email, usually on their own card "just to get started." Nobody means any harm. It is simply the fastest path on day one.
The cost shows up later. A developer moves on, gets busy, or the relationship ends badly, and suddenly the founder finds out that the app store listing, the domain, or the production database belongs to someone else's login. Even with full goodwill on both sides, moving things across accounts takes time, and some things are painful to move at all.
So I treat ownership as part of the setup work, not something to tidy up at the end. It costs almost nothing in week one and a lot in month twelve.
The full list of things you should own
Here is the checklist I go through with clients. Not every project needs every item, but every item on it is something I have seen matter.
1. The code repository
Your code should live in a GitHub (or GitLab, or Bitbucket) organization that your business owns, with the developer added as a member. Not a repository on the developer's personal account that they "will transfer later."
Owning the organization means you control who has access, you keep the full history, and you can bring in another engineer, an auditor, or a future in-house team without asking anyone's permission. It also means CI/CD secrets and build pipelines sit in a place you control, which matters more than people expect. At Geonode I set up Unity and Windows CI/CD pipelines, and that kind of build infrastructure is a real asset that should belong to the company, not to whoever wrote the config.
2. The domain and DNS
The domain should be registered in your name, with your email as the account owner, at a registrar you can log into. DNS controls your website, your email deliverability, and often your app's API. Whoever controls DNS can take your product offline with a few clicks, so it should be you.
3. Cloud and hosting accounts
AWS, Firebase, Azure, Vercel, whatever the stack runs on. Create the account (or the organization) under a business email and a business card, then give the developer the access they need. With most providers you can grant broad access to a project without handing over ownership of the billing account.
This also keeps the bill honest. When the hosting cost arrives on your card every month, you see what your product actually costs to run, which matters even more for AI products where usage drives the bill. I wrote about that side in AI app unit economics.
4. Apple and Google developer accounts
This is the one I push hardest on, because it is the most painful to fix later. Your app's store listing, its reviews, its download history and its bundle identifier all live inside a developer account. If the app was published from a developer's personal account, moving it to yours is possible but it is a formal transfer process with conditions, and you cannot do it without that developer's cooperation.
Enroll your company in the Apple Developer Program and create a Google Play Console account in the company's name from the start. Apple's organization enrollment asks for a D-U-N-S number for your business, which can take time to get, so start early. At RAQTS I managed App Store and Play Console releases for the mobile apps, and the accounts belonged to the company with me added as a team member. That is exactly how it should be. Store review has enough surprises of its own (I covered the common ones in app store review rejections) without account ownership being one of them.
5. API keys for paid services
OpenAI, Anthropic, Gemini, speech-to-text, maps, payments, email sending. Every paid API your product depends on should be an account you own, with keys generated from your dashboard.
There are two reasons. The first is control: if the key lives in the developer's account, your product stops working the moment they cancel their card or rotate their keys for an unrelated project. The second is visibility: you want to see usage and set spending limits yourself, especially on anything driven by a model.
6. Voice AI, phone numbers and messaging
For the voice agent projects I build, this category is its own checklist. The voice platform account (Retell AI in most of my work), the telephony account and phone numbers (often Twilio), and the business texting registration should all be in the client's name.
Phone numbers are the trap here. Your customers learn your number, it goes on your website and your signage, and it is far harder to move than code. US business texting registration is also tied to your business identity, so it belongs to you by nature. I explain that process in A2P 10DLC registration for voice agent SMS, and number setup in AI receptionist phone number setup.
When I hand over a voice agent, the accounts are already the client's, so the handover is about knowledge, not transfers. That is the approach in handing over a voice agent to a client.
7. CRM and automation workspaces
GoHighLevel, n8n, Make, Zapier, Airtable. These hold your customer data and the logic that moves it around. In the CallSetter AI work at Tested Media, GoHighLevel was the CRM behind campaigns and lead management, and that data is the client's business. The workspace should be theirs, with automations built inside it rather than in a developer's personal instance that happens to call their API.
Agencies sometimes run client sub-accounts under their own agency account, which is a legitimate model. If that is your setup, get it in writing what happens to your data and your automations if you leave.
8. Design files and documentation
Figma files, brand assets, architecture notes, the list of every service and what it does. Ask for these to live in shared folders you own, not to be "sent over at the end." Documentation that exists only in a developer's head is not documentation.
How to set this up without slowing the project down
The objection I hear is that this adds friction at the start. It adds about an hour, if you do it in the right order:
- Create a shared business email for technical accounts, something like tech@ or dev@ your domain, that more than one person at your company can access. Using a founder's personal inbox is a smaller version of the same problem.
- Store credentials in a password manager that your company owns, and share a vault with the developer. No passwords in chat messages or emails.
- You create the account, then invite the developer. For services that genuinely need the developer to create something (some do), they create it under your organization and you confirm you are the owner before any real work goes in.
- Use the business card for billing wherever possible. If the developer has to pay for something to unblock work, they invoice it to you and move the subscription to your card at the next billing cycle.
- Keep a simple access sheet: service, owner login, who has access, what it costs per month. This one page is worth more than most technical documentation at the moment someone leaves.
Red flags when a developer will not do this
Most developers are glad to work this way. It protects them too, because nobody can later claim they are holding anything hostage. Be careful if you hear:
- "It is easier if I just publish it from my account." Easier for the first week, much harder for every week after.
- "I will transfer everything at the end." Sometimes true. Often the end gets fuzzy, and transfers are never as quick as promised.
- "You do not need access, I will handle it." You do not need to log in every day, but you need to be able to.
- Reluctance to put code in your repository until the final payment. Payment terms are a fair concern, but they belong in the contract, not in who holds your source code. Milestones solve this better, and the payment structure discussion is in fixed price vs hourly vs retainer.
This is one of the protections I listed when comparing freelancers, agencies and in-house developers, and it applies to all three. A great agency should be just as happy to work inside your accounts as a solo freelancer.
If you are already in the wrong setup
If some accounts are already on a developer's side, fixing it is usually straightforward while the relationship is good. Go through the list above, write down who owns each item, and agree on a short plan to move the important ones: domain and app store accounts first, then cloud, then API keys and everything else. Rotate keys and passwords once ownership moves.
Do it now, not when the relationship is ending. Transfers are easy between people who are cooperating and very hard between people who are not. It also tends to surface hidden costs and forgotten services, which makes maintenance after launch easier to budget.
The short version
Your developer should have access to everything and own nothing. You should own everything and need to touch very little of it day to day. Set it up that way in the first week, keep a one-page access sheet, and the day someone moves on becomes a handover instead of a crisis.
I work directly with founders and teams in the US, UK and Europe as a hands-on engineer and fractional CTO, across AI voice agents, web and mobile apps, Unity and AR/XR, and I set projects up in the client's own accounts from day one. If you are starting a build or untangling an existing one, more about my background here, or book a call.