Who owns your code? Six things to put in your company's name from day one

Ownership means the account is registered to your company, paid for by your company, and you hold the top role in it. Access means a person can open, change and ship what you allow. You want the first for yourself and the second for everyone who works on the product.

Both sides are tempted to skip this. The developer wants to start. You want to avoid admin. So the developer signs up with a personal email and you say fine. It feels harmless, and it stays harmless right up to the day the relationship changes.

A made-up example: a founder hires a freelancer to build a booking tool. The freelancer keeps the code under a personal username and registers the domain with a personal email. Eight months in, the founder wants a second developer to add a feature. The second developer can't open the repository and can't touch the domain settings. Nothing was stolen. The founder simply doesn't hold the keys to a product they paid for.

Everything below is there to stop that.

The repository is the folder where all the code lives, with the full history of every change. Code hosts such as GitHub let you create an organisation, which is a company-level account that holds repositories and has members with roles.

Why it must be yours: whoever owns the organisation decides who gets in. GitHub's docs describe organisation owners as having complete administrative access. If that's you, you can swap agencies and the code stays where it is.

How to set it up: create your own user account with your company email, then create the organisation from it and create one repository for the product. Invite your developer as a member or as an outside collaborator, with write access to that repository. Turn on two-factor sign-in for yourself and save the recovery codes in the company password manager.

GitHub also says the owner role should be limited, but to no fewer than two people, so you aren't locked out if one login is lost. Make the second owner a co-founder or someone inside the company. Not the agency.

The red flag is code that only exists on one laptop, or in a personal account you can't open.

This is where the live product sits: the servers, the database, the uploaded files, and the bill.

Why it must be yours: the cloud account holds your customers' data. If the account is yours, changing developers is a handover. If it's theirs, changing developers means moving a running system out of someone else's account, and you'll be doing it on their timetable.

How to set it up: sign up with the company email and put the company's payment method on file yourself. Keep the top admin role. Create one project or workspace for the product and invite the developer into that, with a role that lets them build and deploy. Turn on two-factor sign-in. If the provider offers a budget alert, set one, so a runaway bill reaches you too.

I'm not naming providers or menu paths here. They differ, and the screens change. The principle doesn't: you are the admin and the payer, and the developer is a member of one project. Keep the right to delete data or close the account to yourself.

The domain is your address on the web. DNS is the settings page that says where that address points: which server shows the website, which service handles your email. Whoever controls the registrar account controls both.

Why it must be yours: your customers know you by this address, and your email runs on it. If you can't change where it points, you can't move to a new server without the old developer's help.

How to set it up: register the domain yourself at a registrar of your choice, in the company's name, and keep the login. Turn on two-factor sign-in. If the registrar offers a transfer lock, leave it on. Pay for it with the company card and switch on auto-renewal, because a lapsed domain is its own kind of emergency.

Most of the time the developer needs no login here at all. They tell you which records to add, and you add them. If launch week really needs direct access, grant it for that week and remove it afterwards.

If your domain already sits in someone else's account, ask for it to be transferred to yours now, while everyone is still on good terms.

If you ship a mobile app, the store account is the publisher. Customers see its name as the seller. The listing, the ratings and the release history all belong to that account.

Why it must be yours: if the app goes out under your developer's account, it is their app as far as the store is concerned. Moving a listing to another account later needs the old account holder's cooperation, which is exactly the dependency you're trying to avoid.

This is the one item that doesn't fit in an hour. To enrol a company in the Apple Developer Program, Apple asks that the organisation is a legal entity and has a D-U-N-S number, which Apple uses to verify its identity and address. The person who enrols becomes the Account Holder and must have the legal authority to bind the company. Apple also wants a working public website on the company's own domain. Membership costs 99 USD per year.

Google Play asks for a D-U-N-S number for an organisation account too, along with the organisation's name, address, phone number and website, and you have to verify those details before you can publish. Google's help page adds that applying for a D-U-N-S number through Dun & Bradstreet is free, and warns about third parties that charge for it.

So: request the D-U-N-S number first, enrol yourself as the account holder, and then invite the developer with a role that lets them upload builds and edit the store text. Publishing stays your decision. Requirements change, so read the two pages in the sources before you start.

Most products lean on outside services: one for payments, one for sending email, one for maps, one or more for AI features. Each gives you keys, which are long secret codes that let your product act in your name. Whoever holds a key can spend your money or send email as you.

Why they must be yours: a key is spending power. If the accounts are yours, you can cancel one key and issue another the day someone leaves.

How to set it up: for each service, create the account with the company email and enter the payment method yourself. Where the provider offers separate test and live keys, use both. Keep the live keys in the company password manager or in the hosting provider's secret settings. Don't send them through chat or email.

What to hand over: test keys by default. Live keys go into the hosting settings, where the app can read them and people mostly don't need to. A developer who is integrating payments this week may need more access this week. Widen it then, and narrow it again after.

Keep a plain list: which service, which key, where it's stored, who can see it. You'll need that list on the day somebody leaves.

Accounts give you control of the systems. They don't settle who holds the legal rights to the code. That's the contract's job, and the rules on commissioned work differ from country to country. I'm an engineer, and I'm not going to tell you what German law says about it. Have a lawyer read this part before you sign.

What I can give you is the list of questions I'd want the contract to answer, so you know what to ask the lawyer.

Don't let this replace the first five items. A clause says the work is yours. The accounts are what let you open it, run it and move it on a Monday morning without a legal letter.

• Which rights to the code written for this project does the company get, and when: as it's written, or only once an invoice is paid?
• What happens to code the developer brings along from earlier work, and to open-source parts? You'll need permission to keep using them.
• Is the developer obliged to hand over the repository, the documentation and a list of every account and key, and by when?
• What happens to all of this if the contract ends early or there's a dispute about payment?
• Is the final payment tied to a completed handover?

For five of the six, I'd budget about an hour of your own time each, with the developer on a call to tell you what they need. The store accounts are the exception, because verification waits on other parties. The clause is your lawyer's hour, not yours.

I'd change the order from the list above when you do it. Start with the domain and a company mailbox on it, something like a shared accounts address that isn't tied to one person. Every other sign-up asks for an email address, and you want all of them to land there. Then the repository, the cloud account, the service keys, and the store accounts in parallel because they take longest.

Before you begin, have four things to hand: the company's legal name and address, that company mailbox, a company payment method, and a password manager the company controls. Use two-factor sign-in everywhere and store the recovery codes in the password manager, not on your phone alone.

Then invite the developer, one named seat per person. No shared logins. Pick roles that allow daily work and block the three things that matter: changing owners, changing billing, deleting the lot.

The pushback you may hear is "let's set it up under my account for now and move it later". I'd say no. Moving later takes more work than setting it up right, and it needs the cooperation of the very person you may be parting from. If you'd like help with the setup, see product engineering or get in touch.

Every engagement ends, including the good ones. When a developer leaves, remove their access and replace the secrets they could have seen. That's ordinary hygiene, and it protects them as much as you: if something leaks next year, nobody has to wonder about them. Say so up front, in the contract and again in the goodbye message.

Go through the accounts one by one. Remove the person from the code organisation, the cloud project, the registrar if they were ever added, and each store console. Then the keys. Replacing a key is called rotating it, and the order matters: create the new key, put it into the hosting settings, check that the app still works, and only then delete the old one.

Do a test deployment straight after. Some automation was probably set up under the developer's personal login, and removing the person can stop it. You want to find that out the same afternoon, not three weeks later when you need an urgent fix.

Then log in to each account yourself and confirm two things: you hold the top role, and the bill goes to the company.

The prompt below builds the checklist. Paste it into an AI coding agent, opened in your project folder in a mode that only reads. The agent finds the key names in the code. It can't see your accounts, so you paste in who has which role. If the app came to you half finished, the audit I'd run before a rebuild starts with the same ownership check.

Goal: Build my offboarding checklist: every account a departing developer could have had access to, and every key that needs replacing.
Inputs: This repository (configuration, example environment files, deployment files, README). The accounts and roles I know about, pasted here: [list each service, who has access and with which role].
Constraints: Read only. Change nothing. Never print the value of a key. Give only its name and the file it is used in. Do not guess at accounts you find no evidence for. Mark those "to confirm".
Definition of done: Two tables. Accounts: service, the developer's role, how to remove them, done yes or no. Keys: name, service, where it is stored, replaced yes or no. Order the key table so that nothing breaks: the new key is created and installed before the old one is deleted. End with a list of things that may stop working once the developer's own login is removed.