When you hire a freelancer, paying for the code does not on its own make it yours. In the US and the UK, for example, a freelancer who is not your employee generally owns the copyright in what they write until a signed, written agreement transfers it to you. So get a written assignment before the work starts, and separately make sure every account the project runs on is registered to you.
Most people assume the opposite, because it feels obvious: I paid for it, so I own it. Usually nothing bad happens, because most freelancers would never dream of holding code back. The problem shows up later, when you try to sell the company, raise money, or part ways badly, and somebody asks for the paperwork.
Paying for it is not the same as owning it
The detail differs by country, so treat this as the shape rather than the rule where you are. Two well-documented examples:
- United States. Work by an independent contractor only counts as "work made for hire" (owned by the client from the start) if it falls into one of nine specific categories and both sides sign a written agreement saying so. Software is not one of the nine. So for code, what you normally need is an assignment of copyright. The US Copyright Office lays out the rules in Circular 30.
- United Kingdom. The author of a work is its first owner. The exception is an employee writing it in the course of their job, which a freelancer is not. And an assignment of copyright only takes effect if it is in writing and signed by the person assigning it. (Copyright, Designs and Patents Act 1988, sections 11 and 90.)
Both were checked in October 2026. In both cases the answer is the same practical step: a short written clause, signed, that says the rights in the work pass to you.
What "owning the code" needs to cover
"The code" is several different things, and a good agreement names them:
- The code written for you. This is the part that should be assigned to you outright.
- Designs, copy and assets made for the project. Icons, illustrations, screens. Same treatment.
- The developer's own reusable tools. Many developers bring a starter kit, a set of helpers they use on every job. It is fair for them to keep owning that and give you a permanent licence to use it inside your product.
- Open-source libraries. Almost every project uses them. Nobody can assign those to you. They come with their own licences, which your developer should be able to list.
- Paid third-party components. Themes, fonts, plugins. Check the licence is in your name, not theirs.
The clause, in plain words
You do not need a long contract. You need the idea below, in your agreement, in words a lawyer is happy with:
All work created for this project, including code, designs and documentation, is assigned to the client on payment of the related invoice. The developer keeps ownership of their pre-existing tools and code, and grants the client a permanent, royalty-free licence to use them as part of this project. The developer may show the finished work in their portfolio.
Three things make that fair to both sides. Ownership passes on payment, so the developer is not handing over rights to unpaid work. Their reusable tools stay theirs. And they can show the work, which is how freelancers get the next job.
The accounts are a separate problem
Copyright is about who owns the code. Accounts are about who can actually reach it. You can own every line on paper and still be locked out of your own product.
| Account | Should be registered to | Why |
|---|---|---|
| Domain name | You | Controls the site, email and every login link |
| Code repository | Your organisation | So you can see every commit and nobody can delete history |
| Hosting and database | You, on your card | Your users' data lives here |
| Apple and Google developer accounts | You or your company | Moving an app between accounts needs the old owner's help |
| Payments, email sending, analytics | You | Revenue, customer email and data |
| Design files | Your workspace | So the next designer can open them |
Create these yourself and invite the developer in. It takes an afternoon at the start, and it is the single change that turns a developer disappearing from a crisis into an inconvenience.
When to get it done
Before any work starts. At that point it is a routine line in an agreement and nobody thinks twice. Six months in, it becomes a negotiation, and you are negotiating with the one person who holds the thing you need.
If you are already mid-project with nothing written down, it is still easy to fix. Ask for a short signed letter confirming that the work done so far, and the work to come, is assigned to you on payment. A good freelancer will sign it the same day, because it protects them too: it makes clear what they are and are not responsible for.
What a fair developer will ask for in return
Expect, and agree to, three things:
- Payment before the transfer. Rights pass when the invoice is paid. That is reasonable.
- Their tools stay theirs. Their starter code is how they work quickly for everyone. Take a licence, not ownership.
- Portfolio rights. They want to show what they built. If the project is confidential, agree what they can show instead: a description, a screen without data, nothing until launch.
If a developer refuses to assign the code at all, even after payment, that is the time to ask why, and probably to keep looking. It is one of the questions in 20 questions to ask a freelance developer, and the answer should be quick and boring.
The goal is not suspicion. It is a project where, if everyone involved vanished tomorrow, you could still log in, read the code, and hand it to someone new.