Who Owns the Code When You Hire a Freelance Developer?

If a freelancer writes your software, they usually own the copyright until a written contract assigns it to you. That's the short answer to who owns the code a freelance developer writes, and it holds across most of Europe, the UK and the US. Even with the rights on paper, you only really control what you can access: the code repository, the domain, the hosting and every service the app depends on.

I'm a developer based in Denmark, not a lawyer, and copyright rules vary between countries, so treat this as practical guidance rather than legal advice. I take over and extend systems other people have built, and missing rights and missing access are where those handovers get expensive.

The short answer

My rule of thumb: the company owns, the developer borrows. That applies to the legal rights and to the accounts.

If your setup looks different, it may not hurt yet, but it will the day you switch developers, sell the company or raise money. If you haven't picked a developer yet, start with my complete guide to hiring a developer and come back here when it's time for the contract.

Who owns the code if nothing is agreed?

The EU rule is set out in the Software Directive, Article 2(3): when an employee writes a program as part of their job, the employer gets the economic rights. There's no matching rule for contractors. In most European countries, a freelancer therefore keeps the copyright unless the contract assigns it. Hire an agency and its employees write the code, so the rights land with the agency, not with you.

A few national differences to know:

• In Germany, copyright itself can't be transferred, so contracts grant exclusive, unlimited usage rights instead. The practical effect is similar, but the wording matters.
• In the UK, an assignment only works if it's in writing and signed by the person handing over the rights, under section 90(3) of the Copyright, Designs and Patents Act.
• In the US, "work made for hire" covers employees, but commissioned work only qualifies in the nine categories listed in the Copyright Office's circular on works made for hire, and custom software isn't one of them. That's why US contractor agreements usually add an explicit assignment.

Without an assignment you're not left with nothing: under the EU directive, a lawful user can run the program and fix errors. But that doesn't cover new features or let you sell or license the software. A court may also look at what both sides must have assumed, but that's a slow and costly route to something two sentences in a contract would have settled.

Assignment, license or something in between

There are four common models, and the right one depends on how central the software is to your business.

For a system at the heart of your business, I usually recommend the second model. It's fair to both sides and lets any developer carry on the work.

Whichever model you pick, the contract should spell out three things:

1. Every type of use. Many European copyright laws read a grant narrowly, so a right to one use doesn't imply others. Say the assignment covers all forms of use, including ones nobody has thought of yet.
2. The right to modify and pass on. Danish law, for example, doesn't let someone who acquires copyright modify the work or transfer it further unless that's customary or clearly assumed. Write down that you can change and extend the code, also through other developers, and transfer the rights, for instance in an acquisition.
3. The timing. Rights often pass on payment. That's reasonable, but consider having them pass with each paid milestone, so one disputed invoice doesn't leave the whole project without a clear owner.

How to secure ownership in 6 steps

The paperwork is half the job. The other half is controlling the accounts your code lives in, because a perfect contract won't help much if the repo sits in the developer's name the day they stop answering. Work through these steps in order, ideally before the first line of code.

1. Put the assignment in the contract

Add it to the agreement you're signing anyway, or as a short addendum to the developer's standard terms. For the rest of the agreement, from scope to termination, use my freelance developer contract checklist.

2. Create the repo in your own organization

Set up a company organization on GitHub or GitLab and keep the code there. Invite the developer as a member with the permissions the job requires. Make at least two people in your company owners, so you don't depend on a single employee either.

If the code already lives in the developer's personal account, it can be moved. Transferring a repository on GitHub keeps the full history, issues and pull requests.

3. Register the domain with your company as registrant

The registrant is the legal holder of the domain. It should be your company, not the developer or the agency, though an agency can still manage the domain for you. Check it in your registrar's dashboard or through the registry for country domains such as .de, .se or .dk. Changing the registrant usually needs the current holder to start or approve the transfer, which is easy while you're on good terms and hard afterwards.

4. Keep hosting and the database on company accounts

Servers, databases and backups belong on accounts your company opened and pays for with its own card. The developer gets their own login. Never share one account between people, because then you can't remove one person without locking everyone out. Check that you can download a database backup yourself.

5. Open third-party services in your company's name

Payments (Stripe, for instance), email, SMS, analytics, app store accounts and any AI APIs the app calls should all be company accounts. API keys, the credentials the app uses to talk to those services, belong in a password manager your company controls, such as 1Password or Bitwarden, not in an email thread or a chat. Then you can rotate them when a developer leaves.

6. Keep documentation and design files on your side

A short README explaining how to set up and deploy the project is part of what you own. So are design files and the task board. If they live in the developer's own Figma or Notion, you own the code without the manual.

The gray areas: open source, reused code and AI

Open-source packages

Almost all modern software is built on open-source packages, code other people wrote and share freely. Your developer can't assign those to you, because they don't own them; you use them under their own licenses.

Most licenses, such as MIT and BSD, ask very little. Copyleft licenses like the GPL can require you to release your own source code when you distribute the software, and the AGPL can apply even when the software is only used over a network, as a SaaS product is. Ask for a list of significant packages and their licenses.

The developer's own building blocks

Many freelancers reuse generic modules and tools across clients. That's fair, and it often makes your project cheaper. What you need is a perpetual, irrevocable, royalty-free license to those parts that also covers any future developer who has to change them. Otherwise you own the house but not the foundation.

Code written with AI

Plenty of developers now write code with AI assistants. In its January 2025 report on AI and copyrightability, the US Copyright Office concluded that purely AI-generated material isn't protected and that prompts alone are unlikely to be enough. Human contributions, including creative changes to AI output, can be.

The report doesn't bind European courts, but the practical advice holds: have the developer stand behind all delivered code however it was written, and agree that your code and data won't be shared with services that train on them.

If you're already missing rights or access

If your contract says nothing about IP, or the domain is in the developer's name, fix it while the relationship is still working. A signature and an account transfer are far easier to get from a happy developer than from one you've just let go.

1. Read what you have. Quotes, order confirmations and an agency's standard terms often say something about IP, even when there's no formal contract.
2. Ask for a written assignment now. A half-page addendum can be enough. A freelancer who has been paid rarely has a reason to refuse. If an agency's business model is licensing, expect full ownership to cost extra.
3. Move the accounts. Follow the steps above, starting with the domain and the repo.
4. Know what you're taking over. Before paying for the rights to older code, get an external code review so you know whether it's worth building on.

If the developer has gone quiet or things have broken down, my guide on switching developers mid-project walks through the process. If a lot is at stake, talk to a lawyer before you build further on the code.

When full ownership isn't the right goal

I recommend owning the code behind anything core to your business, but sometimes demanding it doesn't pay off:

• Off-the-shelf platforms. On Shopify, a ready-made booking system or any other SaaS product, you'll never own the code, and that's fine. What matters is owning your domain and being able to export your data in a usable format.
• An agency's own product. If your solution is a configuration of a platform the agency sells to many clients, a full transfer will be expensive or impossible. Negotiate a license with a clear exit instead: data export, fair notice periods and possibly source code escrow, where an independent third party holds the code and releases it to you if the vendor shuts down.

That applies if you're considering hiring me, too: if you need a finished product on a fixed monthly fee and no custom development, an off-the-shelf platform is often cheaper than having something built.

Next steps

Start with what you can do this week:

1. Dig out your contract or terms and check whether they assign the IP to you.
2. Go through the checklist above and fix every box you can't tick.
3. Starting a new project? Raise ownership in the first conversation. It belongs on your list of questions to ask a developer before hiring.

For more ways to keep your options open, see my guide on how to avoid vendor lock-in with your developer. If you have a system that needs taking over, tidying up or extending, here's how I handle maintenance and further development of existing apps. With me, the code lives in your own repository from day one.

Frequently asked questions

Do I own the code if I haven't paid the final invoice?+

Often not, but it depends on your contract. Many agreements only transfer the rights on payment, so until the invoice is settled the developer may still hold the copyright. If you dispute the invoice, say so in writing and pay the undisputed part. Withholding payment while using the code can leave you in breach of contract and infringing copyright at once.

Can the developer reuse code from my project for other clients?+

Not the code assigned to you, but they can reuse their knowledge and methods. Copyright protects the code itself, not the ideas and principles behind it, as the EU Software Directive states. A developer can build something similar for another client as long as they don't copy your code or use your confidential information. Preventing more takes a separate, narrowly drafted agreement.

What happens to missing IP rights when I sell the company or raise money?+

They can cost you on price, or in the worst case the whole deal. Buyers and investors check during due diligence whether the company owns its software and ask for the agreements that prove it. A missing assignment from a former freelancer or agency usually has to be fixed before closing, which is easier when you're not under time pressure.

Do I need a lawyer to write the IP clause?+

Not always. For a small project, the developer's standard terms checked against the points in this guide are often enough. For a core product, anything you plan to sell or raise money on, or a contract across borders, a lawyer's review is cheap compared with fixing a missing assignment later, when you have less bargaining power.