Who owns the code and accounts when you hire a developer

When you pay for custom software, you should own the code, the intellectual property in it, and every account the product runs on: the repository, hosting, domain, app store listings and third-party services. None of this happens automatically. The contract has to transfer the rights in writing, and the accounts have to be opened in your company's name from the start, with the developer invited as a user. If both are in place, you can change developers at any time without losing your product.

This article explains the practical side. It is not legal advice, and the rules differ between countries, so have a lawyer review the contract itself.

#Who owns the code by default

Many clients assume that paying an invoice makes the code theirs. In many countries, copyright in software written by an outside contractor stays with the author unless a written agreement transfers it or grants a license. An employee's work is usually treated differently from a contractor's, which is one more reason to put the terms in writing instead of relying on assumptions.

A development contract should say, in plain terms:

• What transfers: the source code, designs, documentation, database structure and any other materials created for the project.
• When it transfers: on payment of each milestone, or on final payment. Transfer per milestone protects you if the relationship ends halfway.
• What the developer keeps: general tools, libraries and know-how they built before your project and use across clients. It is normal for a developer to keep these and give you a permanent license to use them in your product. The contract should list or describe them, so there is no argument later.
• Third-party components: which open-source and commercial components are used, and under which licenses.
• Confidentiality: how your business data and credentials are treated during and after the project.

#Accounts belong in your name from day one

Owning the code is of little use if someone else controls the places where it lives and runs. The rule is simple: every account is registered to your company, with your email address and your billing details, and the developer gets access as a user or administrator you can remove.

Account	What to check
Code repository (GitHub, GitLab, Bitbucket)	The organization or workspace is yours, and you have the owner role.
Domain registrar	The domain is registered to your company as the holder, and you can log in to the registrar account.
Hosting or cloud	The contract and billing are in your name, and you have full administrative access.
Apple Developer and Google Play Console	The apps are published under your developer account, and you hold the admin or account holder role.
Payment, email, maps, analytics, error tracking	Each service is registered to you, and API keys are issued from your account.

Domains deserve particular care, because the legal holder of a domain is whoever is named in the registration, whatever was agreed verbally. Our article on how domain names work covers registration and transfers in more detail. Mobile apps have a similar trap: moving an app between developer accounts is possible, but it is slower and more awkward than publishing under your own account from the first release.

If a developer insists on hosting your product in their own account "to keep things simple", ask what happens when you want to leave. There may be good reasons for managed hosting, but you should still hold the account, or have a written, tested exit path.

#Open-source licenses inside your project

Almost every modern application is built on open-source frameworks and libraries. That is normal and saves a great deal of work, but each component comes with a license, and the license sets the rules.

• Permissive licenses such as MIT, BSD and Apache 2.0 let you use, change and sell software that includes the component, as long as you keep the copyright and license notices. Apache 2.0 also includes terms about patents.
• Copyleft licenses such as the GPL require that, if you distribute software built on the component, you make the source code available under the same license. The AGPL extends this to software that users reach over a network.

Copyleft components are not forbidden, and many companies use them deliberately. The risk is using one without knowing it, in a product you planned to keep closed. Ask the developer for a list of dependencies with their licenses, which package managers can generate, and ask them to flag anything under a copyleft license before it goes in. Paid themes, plugins and fonts also have licenses; check that each one is bought in your name and allows your kind of use.

#Credentials and documentation at handover

A handover is complete when someone who has never seen the project could run it, deploy it and fix it using only what you received. That needs two things.

Credentials

Passwords, API keys and server keys should be stored in a password manager your company controls, never sent in plain email or chat. At handover, go through every entry, confirm it works, and then change the passwords and keys the previous developer knew. Plan that change carefully, because a key that is still hard-coded somewhere will break a feature quietly. The checklist in taking over a codebase another team built goes through this step by step.

Documentation

• How to set up the project on a new machine and run it locally.
• How to deploy, and where each environment (staging, production) lives.
• Where configuration and environment variables are kept, without the secret values themselves.
• An overview of the architecture: main parts, external services and how data flows between them.
• How backups are made and how to restore one.
• Scheduled jobs, queues and anything else that runs in the background.

#What to check before signing

• The contract transfers the IP in the work to you, and says when.
• Pre-existing tools the developer keeps are described, and you receive a permanent license to use them.
• All accounts will be opened in your name, or transferred to you on a stated date.
• The code will live in a repository you own, with full history, from the start of the project.
• Open-source licenses will be listed, and copyleft components flagged.
• Documentation is part of the deliverables, and is kept up to date during the project.
• The contract describes what happens if either side ends it early, including what you receive.

#What to check at handover

• You are the owner of every account in the table above, and can log in without the developer's help.
• The repository contains the full history, all branches, and everything needed to build the product.
• The product builds and deploys from the repository, following the written instructions.
• Every credential is in your password manager, and the ones the developer knew have been changed.
• You have a recent backup, and someone has restored it successfully at least once.
• You have the license list, and paid components are registered to you.

If any of these is missing, ask for it before the final payment. It is far easier to fix while the project is still open.

#How PN Scripts can help

On PN Scripts projects, the code, the accounts (hosting, app stores and domains) and the documentation are in the client's name from day one, and the client owns the IP. If you are planning a new product or want an existing one reviewed, see how we approach custom web development.