Code ownership
Who owns the code when an agency builds your app?
Most people who commission software believe they own the result because they paid for it. Under English law that is usually not true, and the sections that say so are short enough to read in a minute.
What the Act says
Three provisions decide this, and they are worth reading in the original rather than in paraphrase.
Section 11(1). The author of a work is the first owner of any copyright in it, subject to the following provisions. The author is the person who wrote it. Not the person who paid for it, not the person whose idea it was.
Section 11(2). Where a literary, dramatic, musical or artistic work, or a film, is made by an employee in the course of his employment, his employer is the first owner of any copyright in the work subject to any agreement to the contrary. This is the exception everyone half-remembers, and the load-bearing word is employee. An agency is not your employee. A freelancer on a day rate is not your employee. A contractor working through their own limited company is emphatically not your employee.
Section 90(3). An assignment of copyright is not effective unless it is in writing signed by or on behalf of the assignor. Not a verbal agreement, not an exchange of emails about who owns what, not an invoice marked paid in full. In writing, signed, by the person giving it up.
A computer program counts as a literary work under section 3(1)(b), which is how all of this applies to software at all.
So what do you have, if there is no clause?
Usually an implied licence. The courts will not generally let a developer take your money to build you a thing and then stop you using it. But an implied licence is narrower than ownership and its edges are exactly where the disputes are:
| Can you… | Owner | Implied licence |
|---|---|---|
| Use the app as built | Yes | Almost certainly |
| Hand the code to a different developer | Yes | Arguable |
| Modify it substantially | Yes | Arguable |
| Sell the company with the software as an asset | Yes | A problem in due diligence |
| Stop the developer reusing it for a competitor | Yes | No |
That last row is the one that surprises people. Without an assignment, nothing stops the agency that built your product building a very similar one for someone else next quarter.
Where it actually bites
Rarely day to day. It bites at three moments: when you want to change developer and the old one is unenthusiastic about helping, when you raise money and someone does technical due diligence, and when you sell. An unassigned codebase is a standard finding in diligence and it gets fixed retrospectively, which means asking a developer you parted with two years ago to sign something. They may want paying for that. They may not answer.
What to actually put in the contract
Not legal drafting — your solicitor does that — but these are the four things that should be in there, and the last two are the ones that get left out:
- An assignment, not a licence. Present tense, covering all intellectual property rights in the deliverables, with the moment it takes effect stated. Final payment is the usual trigger and a reasonable one.
- A further-assurance line. The developer agrees to sign anything later needed to perfect the assignment. This is what saves you in due diligence.
- The developer reusable libraries, dealt with separately. Any experienced developer brings their own tooling. They will not assign it and should not have to. What you need instead is a perpetual, irrevocable, transferable licence to use it as part of your product. A contract that silently assigns everything is one the good developers will refuse, and a contract that mentions neither is one you will discover the hard way.
- Third-party and open-source components, named. Nobody can assign these, because nobody owns them. What matters is the licences they carry: permissive ones are fine, copyleft ones can impose obligations on anything you distribute. Ask for the list. A developer who cannot produce one does not know what is in your product.
The four things that travel with the copyright
Ownership of the code is necessary and not sufficient. A handover that gives you the copyright and not these leaves you owning something you cannot ship:
- The repository, with you as owner rather than collaborator.
- The Apple Developer and Google Play accounts, in your company name, plus the signing certificates and the Android upload key.
- The domain and DNS, at a registrar you control.
- The backend project and its billing, in your name.
More on recovering these when a project has already gone wrong, on the handover page.
Sources. Copyright, Designs and Patents Act 1988, s.11; s.90; s.3(1)(b) for computer programs as literary works. Quoted verbatim from legislation.gov.uk, retrieved 7 October 2026. The note on s.11(2) and films reflects the 1996 amendment. This is general information about English and Welsh law, not legal advice, and the position differs in other jurisdictions — US law reaches the same practical answer by a completely different route, and Danish law by another again.
Want a contract that settles this?
Every build I take on assigns the copyright to you on final payment, in writing, and hands over the accounts with it. Ask me what that looks like.
Start here →