Who Owns Your Software? Code, Hosting and Handover Explained

When a business pays for custom software, most people assume they own it. Often they do. Sometimes they find out, usually at an awkward moment, that "own" meant less than they thought. The developer has the only copy of the code. The domain is registered to a freelancer's personal email. The app store account belongs to an agency that has since closed.

None of this is hard to prevent. It just has to be dealt with before the work begins, when everyone is on good terms. This article explains the pieces in plain language. It isn't legal advice, so have a lawyer look at your actual contract, but it should help you know what to ask.

Three different things people call "ownership"

When someone says "I own my software", they could mean any of three things, and they're not the same:

• The code: the files that make the product work.
• The accounts: hosting, domain, app stores, payment gateway, email service, analytics.
• The rights: the legal permission to use, change, sell and stop others copying what was built.

You need all three. Having the code without the hosting login means you can't run it. Having the accounts without the code means you can't change it.

The code

By default, in many countries the person who writes a piece of code holds the copyright to it, unless an agreement says otherwise or they are an employee writing it as part of their job. That surprises people. Paying for the work does not automatically transfer the rights.

So the contract should say, in plain words, that the intellectual property in the delivered work passes to you on payment. Look for two details:

• when the transfer happens (on final payment is common and reasonable)
• what's excluded, since developers legitimately reuse their own general tools and open-source libraries, and those come with their own licences

That second point is normal. What you want is clarity: a list of third-party components and their licences, so nobody is surprised later.

The repository

Code lives in a repository, usually on a service like GitHub or GitLab. The cleanest arrangement is that the repository sits in an organisation account that you own, with the developers invited in as collaborators. If the work is done in the agency's own account, make sure the contract says a complete copy, including history, will be transferred to you at the end.

The history matters. It's the record of why things were done. A bare copy of the final files is much harder for the next developer to work with.

Accounts and credentials

This is where most real-world trouble happens. Make a list of every service the product depends on, and put your company's name and an email address you control on each one:

• domain name registrar
• hosting or cloud provider
• app store developer accounts (Apple and Google)
• payment gateway
• email, SMS and WhatsApp providers
• analytics, error tracking and monitoring
• any AI or map services with API keys

The developer can be given access to work in them. The account itself, and the billing, should be yours. This also protects you from surprise bills and from a vendor holding your site hostage in a dispute.

A simple habit: use a shared mailbox such as tech@yourcompany.com as the owner address, not one person's inbox, so that a staff change doesn't lock you out.

What a good handover contains

At the end of a project, ask for these as a package, not piecemeal:

1. Source code with full history, in a repository you control.
2. Environment details: how to run it locally and how it's deployed, step by step.
3. Configuration: a list of settings and secrets the product needs (the secrets themselves shared securely, never in an email).
4. Database: a backup and a description of how data is structured.
5. Documentation: even a few pages on how the main parts fit together is valuable.
6. Account list: every service, who owns it, and how to recover access.
7. Backup and recovery steps: what is backed up, how often, and how to restore.

A practical test is to ask a different developer, someone with no connection to the original team, to read the handover and tell you whether they could take over. If they say yes, it's good. If they come back with twenty questions, you've found the gaps while you still have leverage.

Questions to put to your developer or agency

• Who will hold the copyright in what you deliver, and when does it transfer?
• Which open-source or paid components are used, and under which licences?
• Will the code be developed in a repository I own?
• Will every third-party account be set up in my company's name?
• What is included in a final handover, and is there a fee for it?
• If we stop working together, how quickly can another team take over?

Any firm that has done this properly before will answer these without fuss. If a question makes them defensive, pay attention to that. We cover other things worth checking in ten questions to ask before hiring a development company.

What if you're already in a messy situation?

It happens, and it can usually be fixed, but the order matters.

1. Make an inventory of every account and who currently controls it.
2. Ask for access and ownership transfers in writing, politely, with a date.
3. Get a full copy of the code and database, and check it actually runs somewhere else.
4. Only then consider changing vendors.

If the product is old or poorly documented, a short technical review can tell you how much it would cost to take it over, and whether it makes more sense to rebuild parts of it. Our piece on modernising old business software covers that decision.

In short

Ownership is not complicated, it's just rarely discussed. Put the code, the accounts and the rights in your name, in writing, before the first line is written. Then a change of team, a change of vendor or a change of plan becomes an inconvenience rather than a crisis.

If you're planning a project and want to set it up this way from day one, talk to us. It's how we work.