Most people assume that if they pay someone to write software, they own it. It is the intuitive answer, it is how buying almost anything else works, and in a surprising number of jurisdictions it is wrong by default.
The gap between "I paid for it" and "I own it" is a contract clause. When that clause is missing - and it is missing more often than you would expect in a short proposal or an email agreement - the person who typed the code may still hold the copyright in it, even after you have paid the final invoice.
This is a plain-English guide to who owns what, what to look for in an agreement, and the handful of ownership questions that catch people out well after launch. It is not legal advice; get a lawyer to review anything you are about to sign.
The default is not what you think
Under US law, copyright belongs to the author the moment the work is created. There is an exception - "work made for hire" - where the employer or commissioning party is treated as the author instead. That exception is narrower than most people assume.
The US Copyright Office sets it out in Circular 9. In summary, a work is made for hire in one of two situations:
- An employee created it within the scope of their employment. Your in-house developers' output belongs to the company automatically.
- It was specially commissioned AND falls into one of nine enumerated categories AND there is a signed written agreement saying it is a work made for hire.
The problem for software buyers is the second route. Those nine categories are things like contributions to a collective work, translations, atlases and instructional texts. Custom software is not one of them. So an independent contractor's code generally cannot be a work made for hire at all, no matter what the contract calls it.
This is the trap. A contract that says "all work shall be considered a work made for hire" and stops there may transfer nothing, because software does not qualify for that category. What you need alongside it is an explicit assignment of copyright.
The clause you want does both: it says the work is made for hire to the extent permitted by law, and that to the extent it is not, the contractor irrevocably assigns all right, title and interest to you. Belt and braces. Almost every well-drafted software agreement contains some version of this, and its absence is worth asking about.
What "owning the code" actually covers
Ownership is not one thing. A real engagement produces several categories of material and they are rarely all owned the same way.
| What it is | Who normally owns it | What to check |
|---|---|---|
| Custom code written for you | You, on full payment | Explicit assignment clause exists |
| Designs, Figma files, brand assets | You, on full payment | Source files handed over, not just exports |
| Agency boilerplate and internal tools | The agency | You get a perpetual licence to use it in your product |
| Open-source dependencies | Their authors | Licences are compatible with your use |
| Commercial third-party licences | The vendor | Licence is in YOUR name, not the agency's |
| Data your users generate | You | Stated plainly, with an export path |
| Infrastructure accounts | You, ideally | Cloud accounts in your name from day one |
The third row is the one people argue about, usually unnecessarily. No competent agency starts every project from an empty folder - they bring internal libraries, scaffolding and patterns built over years. Demanding they hand you the copyright in all of it is unreasonable and most will refuse. What is reasonable, and standard, is a perpetual, worldwide, royalty-free licence to use that material as part of the thing they built for you, including the right to modify it and to let a future developer maintain it.
Open source is not a loophole, but it is a constraint
Nearly every modern web application is mostly other people's code. That is normal and good. But those components come with licences, and the licences travel with them.
Most of what you will encounter is permissive - MIT, Apache 2.0, BSD - which in practice means you can use it commercially, modify it and ship it, provided you keep the licence notices. Some licences are copyleft, and a few of those can impose obligations on the code you combine with them. The Open Source Initiative's licence list is the canonical reference for what is what, and SPDX maintains the standard identifiers that tooling uses.
What to ask for:
- A dependency inventory with licences, generated by tooling rather than typed by hand.
- Confirmation that nothing copyleft is linked into your proprietary code in a way that creates obligations you did not intend.
- A note of any commercial components and whose name the licence is in.
That last point matters more than it sounds. If a paid UI library, font licence or API key sits in the agency's name, your ownership of the code does not help you - the thing stops working when the relationship ends. Every commercial licence should be purchased in your name, billed to you.
The ownership questions nobody thinks to ask
Whose cloud account is production in? You can own every line of code and still be stuck if the running system lives in infrastructure you cannot access. Insist that AWS, Vercel, database and DNS accounts are yours from day one, with the agency added as a user. This is the single most common form of accidental lock-in, and it is trivial to avoid at the start and painful to unwind later.
Who holds the domain? More than one business has discovered at renewal time that its domain was registered by a former supplier.
Where does the source live? Your own version control organisation, not the agency's. If a handover means "they will send us a zip", you do not have the history, the branches, or the record of why anything was done.
Is the deployment reproducible by someone else? Ownership in practice means another team can take it over. That needs documented environment variables, a documented build and deploy process, and access to the pipeline. Code without the ability to deploy it is an artefact, not an asset.
What happens to the code if you stop paying mid-project? Usually, ownership transfers on payment - so partial payment means partial ownership, or none. That is reasonable, but you should know it before there is a dispute, not during one.
Payment and ownership are linked, deliberately
Almost every agreement ties transfer of ownership to payment in full. That is normal and fair: it is the supplier's main protection against non-payment, in an industry where the deliverable can be copied infinitely at zero cost.
What you should look for is that the link is clear and time-bound. "Ownership transfers on receipt of final payment" is clean. Something vaguer, or a clause that lets the supplier revoke your licence later for reasons other than non-payment, is not.
If you are paying in milestones, ask what you own if the project stops after milestone two. The good answer is that you own everything covered by the invoices you have paid, delivered in a usable state.
Data, privacy and the thing you cannot assign away
Your users' personal data is a separate matter from code ownership, and it does not work the same way. Under the GDPR you are typically the controller and your agency is a processor, and the controller's obligations cannot be contracted away - see the text of the regulation for the definitions and the right to erasure. In the US, the FTC's business guidance is the practical starting point.
Practically, your agreement should say:
- The agency processes personal data only on your documented instructions.
- It will help you respond to user requests for access or deletion.
- It will tell you promptly about any breach.
- It deletes or returns the data when the engagement ends.
You cannot outsource responsibility for your users' data. You can and should make explicit what your supplier will do to help you meet it.
A short clause checklist
Before signing, confirm the agreement contains all of these:
- Assignment, not just "work made for hire", covering all custom code, designs and documentation.
- A perpetual licence to any pre-existing agency material embedded in the deliverables.
- Ownership on payment, with what you own if the project ends early spelled out.
- A dependency and licence inventory as a deliverable.
- Commercial third-party licences in your name.
- Repositories and cloud accounts in your organisation.
- A defined handover: documentation, runbook, environment variables, deploy process.
- Data processing terms covering instructions, deletion, breach notification.
- A portfolio clause you are comfortable with - most agencies want to show the work, and it is reasonable to allow it while excluding anything confidential.
Nine clauses, most of them one paragraph each. Getting these right costs an hour of a lawyer's time at the start and removes the entire category of ownership disputes later.
Three ways this goes wrong in practice
Composites, but each is a pattern rather than a one-off.
The zip file handover
A company ends a two-year relationship amicably. They ask for their code and receive a zip file. It contains the source, which they do own, and nothing else: no commit history, no branches, no record of why any decision was made, no environment variables, no deployment documentation.
The code compiles. Nobody can deploy it, because the build depends on four environment variables whose values live only in the previous supplier's CI settings, and one of them is an API key for a service registered to the supplier's email address.
Cost to recover: roughly three weeks of a new team's time, most of it reverse-engineering configuration.
What would have prevented it: the repository in the client's own organisation from day one, and production in the client's own cloud account. Both are free at the start.
The clause that transferred nothing
A five-page agreement said all deliverables "shall be considered works made for hire". No assignment clause. When the client later wanted to license their platform to a partner, their lawyer flagged that software is not one of the nine categories eligible for work-made-for-hire treatment - so the clause may have transferred no copyright at all.
The original developer was cooperative and signed a retrospective assignment. Had they been unreachable, uncooperative, or out of business, the position would have been considerably worse.
What would have prevented it: one extra sentence. "To the extent any deliverable does not qualify as a work made for hire, Supplier hereby irrevocably assigns all right, title and interest in it to Client."
The font licence nobody owned
A brand refresh shipped with a commercial typeface licensed in the agency's name. Eighteen months later the agency's licence lapsed. The foundry contacted the client. The client owned all the code and had no right to the font their entire brand was built on.
What would have prevented it: every commercial licence bought in the client's name, billed to the client, from the start. This applies to fonts, UI component libraries, icon sets, stock imagery, map tiles and any paid API.
Reading the clause: good wording versus bad
You do not need to draft this, but you should be able to spot which one you have been sent.
| What it says | What it means | Verdict |
|---|---|---|
| "All work shall be a work made for hire." | May transfer nothing for software | Not sufficient alone |
| "...and to the extent it is not, Supplier assigns all right, title and interest." | Copyright transfers either way | This is the one you want |
| "Client receives a licence to use the deliverables." | You do not own it; you rent it | Ask why |
| "Ownership transfers upon payment in full." | Normal and fair | Fine, confirm partial-payment position |
| "Supplier retains ownership of all frameworks and libraries." | Standard, if paired with a licence to you | Check the licence is perpetual and irrevocable |
| "Supplier may revoke the licence at its discretion." | Your product can be switched off | Refuse |
The fifth row is worth dwelling on, because it is where reasonable and unreasonable look similar. An agency keeping its internal libraries is normal. The licence they grant you over them needs four words in it: perpetual, irrevocable, worldwide, royalty-free - and ideally the right to modify and to sublicense to a future contractor. Without "irrevocable" the arrangement can end. Without "modify" your next developer cannot fix a bug in it.
Source code escrow, and when it is worth it
Escrow means a third party holds a copy of the source, released to you if the supplier goes out of business or breaches the agreement.
When it makes sense: you are licensing software rather than owning it, and the supplier is a company whose disappearance would stop your operations. Common in enterprise procurement, and reasonable there.
When it is theatre: you already own the code and hold it in your own repository. Escrow adds cost and process to protect against a risk you have already eliminated. If someone proposes escrow on a custom build, ask why the code is not simply in your repository instead. That is cheaper, simpler and strictly better.
Ownership plus your own repository plus your own cloud accounts makes escrow unnecessary. If a supplier resists all three and offers escrow instead, they have proposed the expensive solution to a problem they created.
Objections, and honest answers
"Our agency says handing over the repository is not how they work." Then ask what happens when the relationship ends, and get the answer in writing. There are legitimate variations - some teams work in their own org and mirror to yours - but "you get it at the end" is not one of them, because the end is exactly when trust is lowest.
"Is it reasonable to demand their internal libraries?" No, and pushing hard on it usually costs you goodwill for no gain. What is reasonable is a licence broad enough that another developer can maintain the result. Aim there.
"We are a small project, do we really need all nine clauses?" The nine points cost an hour of legal review once. The cheapest of the three scenarios above cost three weeks. Scale the formality if you like, but the assignment clause and the accounts-in-your-name point are not optional at any size.
"What if we cannot get the supplier to change the contract?" Some will not, particularly larger firms with standard terms. Then price the risk: keep more of the payment until later, keep the accounts in your name even if the code terms are imperfect, and know that you may be buying a licence rather than an asset. That can still be the right deal, as long as you know which one you are signing.
"Does any of this change if the developer is overseas?" The practical advice does not: assignment clause, your repository, your accounts, licences in your name. The enforcement picture does, because pursuing a contract across borders is slower and more expensive. Which is an argument for making the practical controls stronger, not weaker.
The handover checklist
Ownership is only real if someone else can pick the work up. Ask for these as named deliverables, not as goodwill at the end.
| Deliverable | Why it matters |
|---|---|
| Repository with full commit history | A zip has no record of why anything was done |
| README that gets a new developer running locally | The single best test of whether handover is real |
| Environment variable list, with what each does | The most common reason a handed-over build will not deploy |
| Deployment runbook | Including how to roll back |
| Infrastructure inventory | Every service, who it is billed to, what it costs |
| Dependency and licence inventory | Generated by tooling, not typed |
| Database schema and migration history | So the next team can evolve it safely |
| Access to monitoring and error tracking | Owning an app you cannot observe is owning a black box |
| A recorded walkthrough | One hour of screen recording saves a week of archaeology |
The best single test of whether a handover is genuine: can a developer who has never seen the project clone the repository, follow the README, and have it running locally within an hour? If not, you have received files rather than a system.
What to do if you are already in a bad position
If you are reading this because the relationship has already ended badly, the order of operations is roughly:
1. Establish what you actually hold. Do you have the repository, or a copy? Are the cloud accounts in your name or theirs? Whose email registered the domain? Write it down before doing anything else.
2. Secure what you can, immediately. Change what you control. Register domains in your own name at the next renewal. Move DNS if you can.
3. Read the agreement properly. Look for the assignment clause, or its absence. Look for what payment triggered. Look for a termination clause describing handover obligations - many contain one that never got exercised.
4. Ask before escalating. Most former suppliers hand things over when asked plainly. Relationships end for ordinary reasons and few people want a dispute.
5. Get the retrospective assignment signed. If the original agreement lacked one, a short assignment document signed now is far cheaper than the alternative, and most suppliers will sign it.
6. Rebuild access from the outside in. Where credentials are genuinely lost, most services will transfer an account to a paying customer with proof of ownership. Tedious, usually possible.
The thing that turns this from awkward into expensive is time. Every month that passes makes the previous supplier harder to reach and the system harder to reconstruct.
How we handle it
On full payment, all custom source, designs and assets created for your project are yours outright - by explicit assignment, not by hoping "work made for hire" covers software. Our pre-existing libraries stay ours and you get a perpetual, worldwide, royalty-free licence to use them within your product, including the right to modify them and hand them to another team.
Code lives in your repository and production runs in your cloud accounts from the first deploy, not at handover. We tell you what third-party components are in your build and under which licences. And unless you ask us not to in writing, we will show non-confidential visuals of the work in our portfolio.
The specifics are in our terms of service. If you want to talk through an agreement you have been sent by someone else, we are happy to read it and tell you what we would push back on.
Related reading
- Software Development Contract Checklist - the clauses that decide it
- How to Choose a Web Development Agency - asking before you sign
- What Happens After Launch - the handover where ownership is tested
- Why Full-Stack Ownership Beats Handoffs - who is accountable while it is being built
Sources and further reading
- US Copyright Office, Circular 9: Works Made for Hire - why software commissioned from a contractor usually needs an assignment clause
- Open Source Initiative licence list - the canonical reference for what each licence permits
- SPDX licence identifiers - the standard tooling uses to inventory dependencies
- GDPR - controller and processor obligations for user data
- FTC privacy and security guidance - the US practical baseline
