Who owns the code when you outsource? IP ownership explained

Who owns the code depends on your contracts and local law, not on who paid for it. In many countries, code an employee writes as part of their job belongs to the employer, but code from an outside agency or freelancer generally stays with its creator unless a written agreement transfers it to you. So get a signed IP assignment and keep every account in your company's name.

Ownership has two layers, and founders usually think only about the first. One is the legal right to the code. The other is practical control of the repository and the accounts that run your product. You need both, and both are cheap to sort out at the start of a project and expensive to repair at the end.

Who owns the code by default?

Copyright in software generally exists automatically from the moment the code is written. You do not have to register anything for it to exist. The real question is who holds it, and two defaults are common in many countries:

• Employees: code written by an employee as part of their job generally belongs to the employer.
• Contractors and agencies: code written by an independent freelancer or agency generally stays with them, unless a written agreement assigns it to you.

Rules vary by country, and some countries treat software or commissioned work in their own way. With your company in one country, your agency in another and a subcontractor in a third, it can be genuinely unclear which default applies. A clear written assignment makes the default irrelevant, which is the whole point.

Paying for it is not the same as owning it

The natural reaction is “but I paid every invoice.” Where there is no written assignment, a court may well find that you have a right to use what you paid for. A right to use is much narrower than ownership, though. It may not let you sell the code, license it to others, stop the agency from reusing it, or show an investor that the company owns its core asset.

Where ownership problems actually show up

Nobody argues about IP while a project is going well. The question tends to surface at one of these moments:

• Fundraising. Investors ask whether the company owns its technology. Missing assignments often become a condition you must fix before the money arrives, usually under time pressure.
• Selling the company. A buyer is paying for the code, so gaps in the chain of ownership can delay the deal or reduce the price.
• Changing agencies. If the old agency owns the code or controls the accounts, the switch starts with a negotiation instead of a handover.
• Payment disputes. If ownership passes only after the final payment, a disagreement over one invoice can leave the whole product in limbo.
• The agency disappears. If the only copy of your code sits in an account the agency controls and the agency closes, getting it back can be slow and uncertain.

If investors are on the horizon, the technical due diligence checklist shows how IP fits alongside everything else they examine.

What your development contract should say about IP

You do not need a long contract. You need a few clauses that leave no room for doubt. When a founder asks me to look over an agency or freelance agreement, these are the points I check before it goes to their lawyer:

1. A clear assignment. All rights in the work created for you transfer to your company. Lawyers often prefer wording that assigns the rights as the work is created over a promise to assign them later.
2. A wide definition of the work. Source code, designs, documentation, database schemas, tests, scripts and infrastructure configuration, not just “the software.”
3. Ownership that follows payment, milestone by milestone. Many agencies transfer rights only on final payment. Ask for each milestone's work to transfer when that milestone is paid.
4. Every contributor covered. The agency confirms that its employees and subcontractors have assigned their rights to it, so it actually holds what it is passing to you, and it tells you before bringing in subcontractors.
5. Moral rights handled. Some countries give creators personal rights, such as being named as the author, that cannot always be transferred. Contracts often deal with them through a waiver or a promise not to assert them, where the law allows.
6. Help with paperwork later. The agency agrees to sign whatever is reasonably needed to confirm your ownership in the future, for example during due diligence.
7. Confidentiality. Your business logic, designs and data stay confidential and are not reused for other clients.
8. Source code as a deliverable. Delivery means source code in your repository, not a compiled app or a hosted site you cannot touch.

The same applies to everyone who writes code for you: freelancers, a fractional CTO under contract, and your co-founders, including anything written before the company existed. This is general information, not legal advice; have a qualified lawyer review your contracts for your country.

Pre-existing code, licenses and open source

An assignment covers what was created for you. Most products also contain plenty of code nobody wrote for you, and each kind needs its own check.

The agency's own toolkit

Good agencies reuse their own starter templates, components and internal libraries. That is a benefit, since you are not paying to reinvent a login screen, and it is reasonable for them to keep owning that toolkit. In return, you need a license to it that is:

• perpetual and irrevocable, so it survives the end of the relationship
• royalty-free, with no ongoing fees
• transferable, so it survives a sale of your company
• wide enough to let any future developer modify and maintain it

Ask for a short schedule listing the pre-existing components. Without one, nobody can say later which parts are theirs and which are yours.

Paid components and assets

Commercial libraries, UI kits, themes, fonts, icon sets and stock images all come with their own licenses. Trouble starts when they are bought in the agency's name. Have your company buy them, or get written confirmation that the licenses transfer to you.

Open-source licenses

Nearly every modern product is built on open-source packages, and that is normal. The licenses differ, though. Permissive licenses such as MIT and Apache mainly require you to keep copyright and license notices. Copyleft licenses such as the GPL can require you to make your own source code available under the same license if you distribute software built on them, and some licenses extend similar duties to software people use over a network. Ask for a list of dependencies and their licenses before launch. Standard tools can generate one quickly, and it heads off an awkward conversation in due diligence.

Get the source code, not just the app

Owning the rights is half the job. You also need the code itself, in a state another team could pick up tomorrow:

• A repository your company owns, such as a GitHub organization where you are the owner and the agency's developers are invited members. Not the agency's account with you as a guest.
• Access from day one, not at the end of the project. Code you can see every week is code someone can check.
• The full history, not a zip file of the final version. The commit history shows who changed what, and when.
• Everything needed to run it: build and deployment steps, a list of environment variables and external services, database migrations and infrastructure configuration.
• Design source files in a workspace you own, rather than exported screenshots.

A simple test: could a competent developer who has never met your agency get the product running from the repository alone within a day or two? If not, something is missing.

The accounts that decide who really controls your product

Code is what founders think about. Accounts are what actually lock them in. If an agency opens your hosting, domain or app store account in its own name, it controls your product in practice, whatever the contract says about IP.

The pattern never changes: the company owns the account, pays for it and holds the top-level admin login, ideally through a shared company email address rather than anyone's personal one. The agency gets its own users with the permissions it needs, which you can remove in minutes when the work ends. Lock-in through accounts is one of the classic reasons outsourced projects fail, and the easiest one to prevent.

If you are mid-project and accounts are in the wrong place, moving them is usually simple while the relationship is good and much harder once it is not. That is why securing access comes first when you switch development agencies.

Do you need source code escrow?

Escrow means a neutral third party holds a copy of the source code and releases it to you if agreed events happen, such as the vendor going out of business or failing to support the software. It is mainly meant for companies that license software they cannot otherwise see.

For custom software you own, escrow mostly solves a problem you should not have. If the code lives in your repository and the accounts are in your name, you already hold everything escrow would release. It earns its keep when you depend on a vendor's platform that you license rather than own, such as a white-label product at the heart of your business. In that case, ask what triggers a release, how often the deposit is updated, and whether anyone checks that the deposited code actually builds.

Your code ownership checklist

Work through this for every agency, freelancer and contributor, past and present:

• A signed IP assignment covering code, designs, documentation and configuration
• Ownership passing milestone by milestone as you pay, not only after the final invoice
• Written confirmation that the agency's staff and subcontractors have assigned their rights
• A schedule of pre-existing components, with a perpetual and transferable license for you
• Paid libraries, fonts, themes and assets licensed to your company
• A list of open-source dependencies and their licenses
• Every repository in your company's organization, with full history and you as owner
• Hosting, domain, DNS, app store, payment and email accounts in the company's name
• Build, deployment and environment documentation stored in the repository
• Assignments from any founder or early contributor who wrote code before the company existed
• A record of who has admin access to what, reviewed whenever someone leaves

The bottom line

So who owns the code? Legally, whoever your contracts say. In practice, whoever controls the repository and the accounts. Make sure both answers are your company, because assumptions about ownership tend to fail at the worst possible moment. If you are still choosing a vendor, raise these terms before you sign: how an agency responds is a useful part of choosing an agency you can trust. In my experience, good agencies agree quickly, because they already work this way.