Who owns the source code when you hire a developer

Software source code ownership decides whether you can maintain, change or move the system you paid for. If the contract does not clearly give your business ownership of the code written for it, together with access to the repository, accounts and data, you may depend on one developer indefinitely. Agreeing ownership in writing before work starts is simple; arguing about it after a relationship ends is not.

Source code is the human-readable instructions that make up a piece of software. This guide explains what to look for in a contract and a handover, in plain terms. It is not legal advice: ask a lawyer to review contracts in your jurisdiction. If you are planning a custom system, our custom software service page explains how we work.

Why source code ownership matters

Ownership affects what you can do with your software for as long as you use it.

1. Changing developers. Without the code, a new developer cannot maintain or improve the system.
2. Fixing urgent problems. If the original developer is unavailable, you need access to act quickly.
3. Selling or investing in the business. Buyers and investors may ask who owns the software the business depends on.
4. Security and compliance. You may need to review or audit the code, or show who has access to it.
5. Long-term cost. A developer who controls the code can make leaving expensive, even without intending to.

A worked example

A company commissions a booking system and pays in full, but the contract says nothing about ownership, and the code lives only in the developer's private account. Years later, the developer closes the business. The company still has a running website but cannot change it, fix it or move it without rebuilding from scratch. A single clause and a shared repository would have prevented this.

What the contract should say

Contracts vary by country and provider, but these points are worth covering clearly.

A checklist of contract points

• Ownership of custom code. Code written specifically for your project belongs to your business once the agreed payments are made.
• Delivery of the code. You receive the full code, not only a running website, in a repository you control.
• Pre-existing and reusable components. Anything the developer owned before the project, or reuses across clients, is clearly listed, with a licence that lets you keep using, changing and hosting it.
• Third-party and open-source parts. These are identified, with their licence terms respected.
• Data ownership. Your customer and business data belongs to you and can be exported at any time.
• Accounts and credentials. Hosting, domains, app store accounts and third-party services are in your business's name.
• Handover on termination. What the developer must provide if the relationship ends, and within what timeframe.

Questions to ask before signing

1. Who will own the code once we have paid?
2. Where will the code be stored, and will we have access from day one?
3. Which parts of the system are your own reusable components, and what licence covers them?
4. What happens to our code and data if we stop working together?

Code repositories and access

A code repository is where the source code is stored, with a history of every change. It is the practical side of ownership.

1. Create the repository in your business's account, and give the developer access, rather than the other way round.
2. Make sure you have administrator access, not just read access.
3. Ask for work to be committed regularly, so the repository always reflects the latest code.
4. Keep secrets out of the code. Passwords and keys should live in environment settings, not in the repository.
5. Review who has access when people join or leave the project.

A common mistake and its fix

A common mistake is accepting a zip file of the code at the end of the project as proof of ownership. Zip files are easily incomplete and have no history. The fix is to use a shared repository from the first day, so you can see the code and its history at any time.

Third-party and open-source parts

Almost all modern software uses components written by others.

The Open Source Initiative describes open-source licences as licences that comply with the Open Source Definition, allowing software to be freely used, modified and shared. Different licences carry different obligations, so ask your developer for a list of the main components and their licences.

What a proper handover includes

Whether a project ends as planned or a relationship ends early, a proper handover should give you everything needed to continue.

A handover checklist

• Full source code in your repository, with its history.
• A copy of the database, with instructions for restoring it.
• Uploaded files and media.
• Documentation on how to install, configure and deploy the system.
• A list of all services, accounts and licences the system depends on.
• Access to hosting, domains and third-party accounts, transferred to your business.
• Notes on known issues and unfinished work.

Steps to check a handover

1. Ask a second developer to install the system from the handed-over materials.
2. Confirm it runs and matches the live system.
3. Confirm every account is in your business's name.
4. Change passwords and remove old access once the transfer is complete.

The pricing model can also affect what is handed over at each stage. Our guides on fixed price vs time and materials, what custom business software costs and custom software vs off-the-shelf cover the wider decisions.

Where the system is hosted affects what must be handed over, as our comparison of cloud and on-premise software explains.

Summary

• Owning your source code lets you change developers, fix problems and grow without being locked in.
• The contract should cover custom code, reusable components, third-party parts, data, accounts and handover.
• Use a repository in your business's account from the first day, with administrator access.
• Identify open-source and paid components and their licence terms.
• Check a handover by having a second developer install the system from the materials provided.

Clear ownership protects the investment you make in custom software. If you're planning a software project and want ownership set up properly from the start, you can tell us about it here.