You own the code only if your contract says so. In many countries, including India, Australia and the USA, copyright in software written by an outside contractor generally stays with whoever wrote it unless there is a written assignment. You need an IP assignment clause, access to the source code and accounts held in your name.
Paying the invoice is not enough, which surprises a lot of business owners, often at the worst possible moment: when they want to change developers, raise investment or sell the company. This guide explains the key concepts in plain English and lists the clauses to check. It is general information, not legal advice; for a significant project, have a lawyer in your jurisdiction review the contract. Contracts are one step in commissioning software; the rest of the journey is in our custom software guide for growing businesses.
What does "owning the code" actually mean?
Owning the code means holding the intellectual property (IP) rights in it, chiefly copyright, so you can change, copy, sell or license the software without anyone's permission. Having a copy of the files is not the same thing.
Three separate things are often confused:
- IP ownership is the legal right. It comes from law and contracts.
- Source code access is practical: having the human-readable code, not just the running app.
- Account control is operational: who holds the repository, hosting, domain, app store listings and third-party services.
You need all three. Owning the IP without the source code leaves you with a right you cannot use. Having the code without the hosting and domain means someone else can still switch your product off.
Who owns the code by default?
By default, it usually depends on whether the person who wrote it was an employee or a contractor. Employees generally create work that belongs to the employer when it is done as part of their job. Contractors, freelancers and agencies generally keep copyright in what they write unless a written agreement transfers it.
The details vary by country, and there are exceptions, which is exactly why you should not rely on defaults. Put ownership in writing, every time, with every developer you pay.
What is the difference between assignment and licence?
An assignment transfers ownership to you. A licence gives you permission to use something the developer still owns. Both are legitimate, but they give you very different rights.
With an assignment, you can modify the software, hire a different developer, sell the business with the software included, or turn it into a product of your own.
With a licence, your rights are whatever the licence says. It may be exclusive or non-exclusive, limited to certain uses, time-limited, or revocable if you stop paying. Licences are common for agencies' reusable components, white-label platforms and SaaS products.
A fair arrangement for most custom builds is a full assignment of everything written specifically for you, plus a permanent licence for any pre-existing components the developer reuses.
What is "background IP" and why does it matter?
Background IP is anything the developer created before your project, or creates for general use, that ends up inside your software. Think login modules, admin panel templates, internal libraries or deployment scripts.
Agencies reasonably want to keep ownership of these, because they reuse them across clients, and that reuse is part of why projects can be quicker and cheaper. The risk for you is ambiguity. If the contract does not say what is background IP and what licence you get, you may later discover that a critical part of your system is not yours.
Ask the developer to:
- list the background components they expect to use;
- grant you a perpetual, irrevocable, royalty-free licence to use and modify them as part of your software;
- confirm the licence survives if the relationship ends.
How do open-source licences affect ownership?
Most modern software includes open-source libraries. You do not own those, but their licences let you use them, with conditions that differ by licence type.
- Permissive licences (such as MIT, BSD and Apache) generally let you use, modify and include the code in commercial products, with attribution requirements.
- Copyleft licences (such as the GPL) generally require that if you distribute software containing the code, you make your own source available under the same terms.
- Network copyleft licences (such as the AGPL) extend similar obligations to software offered to users over a network, which can matter for web apps and SaaS products.
None of this is a reason to avoid open source. It is a reason to ask your developer to keep a list of the main libraries and licences used, and to flag anything with copyleft obligations before it goes in.
What about code written with AI tools?
Many developers now use AI coding assistants, and that raises open questions. Copyright law in a number of countries generally requires human authorship, so the status of purely machine-generated code is not settled everywhere.
In practice, most AI-assisted code is directed, reviewed and edited by a developer. Rather than banning the tools, ask your contract to include a warranty that the developer has the right to assign everything delivered, that it does not knowingly infringe anyone's rights, and that they follow the terms of any AI tools used.
Which contract clauses should you check?
These clauses decide who owns what and what happens if the relationship ends. Check each one before you sign.
| Clause | What a good version says | What to watch for |
|---|---|---|
| IP assignment | All deliverables created for you are assigned to your company, on payment | "Licence to use" instead of assignment for custom work |
| Timing of transfer | Ownership transfers milestone by milestone as each is paid | Transfer only on final payment of a long project |
| Background IP | Lists reused components and grants you a perpetual licence | No mention at all |
| Source code delivery | Code kept in a repository you own, updated throughout | Code delivered only "on completion" or "on request" |
| Accounts and credentials | Domain, hosting, app store and service accounts in your name | Accounts held by the developer "for convenience" |
| Open-source disclosure | Developer lists major libraries and flags copyleft licences | Silence on third-party code |
| Moral rights | Developer consents to you modifying the work freely | Not addressed, in countries where these rights exist |
| Confidentiality | Both sides protect each other's confidential information | One-sided confidentiality |
| Termination and handover | On termination, you receive all paid-for work, code and documentation | Handover only if you pay extra fees |
"Ownership on payment" is common and fair; a developer is entitled to be paid before handing over rights. Tying it to each milestone, rather than the final invoice, means a dispute late in the project cannot leave you with nothing.
Ownership clauses also interact with how you pay. A fixed-price contract, a time-and-materials arrangement and a dedicated team each create different points at which work is "delivered". We explain those payment structures in our piece on picking a software contract model.
What should a proper handover include?
A proper handover gives a new developer everything they need to take over without calling the old one. Ask for:
- full access to the code repository, including its history;
- admin access to hosting, databases, domain, email sending services and app store accounts;
- environment configuration and secret keys, transferred securely and then rotated;
- documentation of how to build, deploy and back up the system;
- a list of third-party services and who is billed for them;
- a short handover call.
If any of this is hard to obtain, that is itself one of the classic red flags when hiring a software development agency.
How do ownership terms change between in-house and outsourced teams?
With employees, ownership generally sits with you by default, though a clear employment contract still helps. With freelancers and agencies, you need explicit assignment. Our real cost comparison of in-house developers, agencies and freelancers covers the other trade-offs between those models.
Frequently asked questions
If I paid for the software, don't I automatically own it?
Not necessarily. In many countries the author of code keeps copyright unless there is a written assignment, even if you paid in full. Make sure your contract includes an explicit IP assignment clause.
Can a developer reuse code from my project for other clients?
They can reuse their own pre-existing components and general know-how, which is normal. They should not reuse code written specifically for you, or your confidential business logic, if you own it. Spell out the difference in the contract.
What is source code escrow and do I need it?
Escrow means a neutral third party holds a copy of the source code and releases it to you if the vendor fails, for example by going out of business. It is mainly useful when you license software rather than own it. If you own the code and hold the repository, you rarely need escrow.
Should my domain and hosting be in my name?
Yes. Register the domain, hosting, app store developer accounts and key third-party services in your company's name, and add your developer as a user. That way, changing suppliers never puts your live product at risk.
Do I need a lawyer to review a software contract?
For small projects, a careful read using the clause table above may be enough. For anything significant, especially if you plan to raise investment or sell the business, a lawyer's review is worth the cost. Investors and buyers often check IP ownership closely.
Want contracts that put you in control?
We are happy to walk you through how ownership, repository access and handover would work on your project before any money changes hands. Take a look at what we build, then ask us for a fixed-price proposal with the IP terms spelled out.