Who owns the code when you hire a developer or agency?

Key points

• Paying for software does not by itself transfer its copyright in the US, the UK or India.
• A signed assignment of intellectual property is what makes you the owner. Put it in the contract before work starts.
• The developer’s own pre-existing tools and the open-source code inside your product come with licenses, not ownership.
• Open the repository, cloud, domain and app store accounts in your company’s name yourself, and add the developer to them.
• Keep at least two people from your side as owners of every account, and change the credentials when someone leaves.
• This is general information, not legal advice. Laws differ by country, so have a lawyer where you are read the contract.

Why paying for the code does not make you its owner

Copyright starts with the person who creates the work. Code is protected by copyright, so whoever writes it is, by default, its first owner. The main exception in most countries is an employee writing code as part of their job, where the employer owns it. A freelancer or an agency is not your employee, so the default usually does not help you.

How that plays out differs by country. Three examples:

The practical result is the same in all three: if there is no signed document transferring the rights, a developer you hired may still own the code that runs your business. You might hold a license to use it, but you may not be able to sell it, stop them reusing it, or show an investor clean title.

This guide is general information, not legal advice. The rules above are examples, other countries have their own, and details change. Ask a lawyer in your country to read the contract before you sign it.

Work for hire and assignment are not the same thing

Many contracts say the code is a “work made for hire” and stop there. That phrase comes from US law, and it is narrower than it sounds. For a contractor’s work to be made for hire, the US Copyright Office says it must fall into one of nine categories, such as a contribution to a collective work, a translation or a compilation, and both sides must sign a written agreement that says so. If any of those conditions is missing, it is not a work made for hire.

Custom software is not one of the nine categories by name, so a clause that relies only on “work made for hire” may not transfer anything. That is why well-drafted contracts add an assignment as well: a signed transfer of all rights in the work to you. US law requires a transfer of copyright to be in writing and signed by the owner. India’s Copyright Act says the same, and adds that the assignment must identify the work and state the rights, the duration and the territory; if it leaves the last two out, the Act fills them in with limits of its own.

Outside the US, the phrase “work made for hire” may mean little at all. An explicit assignment is the wording that travels.

What to put in the contract

• An assignment of intellectual property: all rights in everything made for you, including code, designs, database schemas, documentation, tests and build scripts, not only the finished app.
• When ownership passes. Some contracts assign everything as it is created; others assign each part when it is paid for. Either can be fair, but the contract should say which, so there is never a gap nobody noticed.
• Everyone who works on it. If the agency uses its staff or other contractors, the agency must hold the rights from each of them before it can assign them to you. Ask how it does that.
• Moral rights, where they exist. In some countries the author keeps personal rights even after assigning copyright. India’s Act gives authors the right to claim authorship and to object to harmful changes, with an exception for certain adaptations of computer programs. Whether these rights can be waived, and how, differs by country, so ask your lawyer what fits.
• A license for pre-existing work. Developers and agencies reuse their own libraries and templates. They will usually keep ownership of those; you need a license to use them in your product that is permanent, does not end if you part ways, and lets another team change the code.
• A list of open-source components and their licenses, delivered with the code, and a rule about which licenses need your approval first.
• Handover duties: what they must deliver when the work ends, including source code, documentation, credentials and access, in a form another team can use.
• Confidentiality, so your product details and data stay private.

Open source: the code you will never own

Almost every product includes open-source code. You do not own it and do not need to: you use it under its license. What matters is that the licenses fit how you plan to ship.

• Permissive licenses, such as MIT and Apache 2.0, mainly ask you to keep the copyright and license notices. You can use the code in a closed product.
• Copyleft licenses, such as the GPL, require that if you distribute software built on the code, you make the complete source available under the same license.
• The AGPL goes further: if you run a modified version as a network service, people who use it over the network are entitled to its source code. That matters for web apps and APIs.

You do not need to read every license yourself. Ask for the list, and ask the developer to flag anything copyleft before adding it, not after.

The practical side: accounts in your name from day one

Paper ownership is only half of it. If the code sits in the developer’s repository, the app in their store account and the domain in their registrar account, you depend on their cooperation to use what you own. Moving things later is possible, but it needs their help, and not everything moves.

App stores show why. Apple lets an app move between developer accounts, but the current account holder has to start the transfer, and some things, such as an Apple Pay merchant ID, do not move with it. Google Play requires both developer accounts to be registered and active, and some data, such as earnings reports and closed testing groups, stays behind. The easy path is to publish from your own account from the first release.

• Code repository: an organization owned by your company, with the developer added as a member or collaborator.
• Cloud hosting and databases: an account billed to your company, with the developer given a role, not the root login.
• Domain name and DNS: registered in your company’s name with an email address you control.
• App store developer accounts: Apple and Google, enrolled as your company.
• Third-party services: email delivery, payments, analytics, error tracking, maps, AI model providers and anything else with an API key. Each account should be yours, with keys issued from it.
• Design files, project boards and documentation: in workspaces your company owns.

Give every account at least two owners from your side, so losing one person never locks you out. GitHub, for example, advises keeping organization owners to a small group of no fewer than two. When someone leaves, remove their access and change the passwords and keys they could see.

If a freelancer already built your app

1. Find the paperwork. Look for any contract, statement of work or terms you accepted, and check for an assignment of rights, not just a promise of delivery.
2. List every account the product touches, and note whose name each one is in.
3. If there is no signed assignment, ask for one now. A short confirmatory assignment covering the work already delivered is common; a lawyer can draft it.
4. Move the accounts into your company’s name one at a time, starting with the repository and the domain, then the cloud, the app stores and the services with API keys.
5. Once everything is yours, change every password, rotate every key and remove access nobody needs.
6. Have someone outside the original team check that the product can be built and deployed from the repository alone. Rewrite vs refactor helps if what you find needs more than a cleanup.

Checklist

• The contract assigns all intellectual property in the deliverables to your company, in writing, signed by both sides.
• It says when ownership passes, and covers everyone who works on the product, including other contractors.
• Moral rights are handled the way a lawyer in your country recommends.
• You have a permanent license to any pre-existing tools or libraries the developer brings.
• You receive a list of open-source components and their licenses, and copyleft code needs your approval.
• The repository, cloud, domain, app store and third-party accounts are in your company’s name, opened by you.
• At least two people at your company are owners of every account.
• The handover terms list code, documentation, credentials and access.
• Credentials are changed whenever someone with access leaves.
• A lawyer in your country has read the contract.

These are the same points worth checking when you compare teams; the rest are in How to choose a software development company. At BYD Tech the code lives in the client’s GitHub from day one, cloud and app store accounts are in the client’s name, and IP is assigned to the client as each invoice is paid; web app development describes the rest of how we work.