Do I own the code if I hire a bespoke software developer?

You have paid for a system to be built. It runs your business. It feels obvious that you own it. So the honest answer catches most people out: paying for software to be written does not, by itself, make you the owner of the code.

That is not a warning about dodgy developers. It is how the law starts, before anyone has behaved well or badly, and it is worth understanding before you sign anything.

The default under UK law is the opposite of what you would expect

Software is protected by copyright, and copyright in the UK is governed by the Copyright, Designs and Patents Act 1988. The Act says the author of a work is its first owner. For code, the author is whoever wrote it.

The important part is what the Act does not say. There is no rule that the person who paid for a commissioned work owns it. When you engage an outside developer or agency to build something, the default is that the developer owns the copyright, and you get an implied licence to use the thing you paid for. Ownership only passes to you if it is assigned in writing, signed by the party giving it up. That is a specific legal requirement, not a formality you can wave away later.

So a business can pay tens of thousands of pounds, run its entire operation on the result for years, and still not own the copyright, because nobody put the assignment in writing. The software keeps working regardless. The problem only shows up the day you want to move to a different supplier, sell the business, or take the code somewhere the original developer would rather it did not go.

Employees are the exception, contractors are not

There is one place the default flips. Under the same Act, when an employee creates a work in the course of their employment, the employer is the first owner. So code written by a member of your own staff, as part of their job, is normally yours automatically.

The catch is that the same rule does not extend to contractors, freelancers or agencies, however it feels in practice. A contractor who sits in your office for six months and writes your system is not your employee, and the employee rule does not apply to them. This is exactly the situation where businesses assume ownership they do not have. If work is done by anyone who is not on your payroll, assume you need a written assignment, and get one.

What "owning the code" actually means

Ownership of the copyright is the legal core of it, but it is not the whole of what you need to walk away and be independent. In practice, owning your software means having all of the following, not just one:

The source code, not only the compiled application that runs. Compiled software you can use; source code you can change. Without the source, another developer cannot pick the system up.

A written assignment of copyright, or at minimum a broad, perpetual, transferable licence, so you can use, change and move the code without asking permission each time.

The repository and its history, so a new developer inherits the full record of how the system was built rather than a single zip file dropped on a shared drive.

The credentials and the deployment: the hosting, the domain, the database, the third-party accounts the system depends on. Code you own but cannot deploy is only half yours.

Enough documentation for someone new to understand it. This is the piece most often missing, and it is the difference between a smooth handover and a costly one. Our guide to how long bespoke software takes covers why handover and documentation are part of the work, not an extra.

You will rarely own one hundred per cent, and that is normal

Almost no modern application is written entirely from scratch. Yours will sit on open-source libraries, frameworks and paid services, and you do not own those. You use them under their own licences, which is exactly how the rest of the industry works too.

That is fine, as long as it is visible. A trustworthy supplier can tell you what third-party components your system relies on and on what terms, so there are no surprises later, such as a component with a licence that restricts commercial use or obliges you to publish your own changes. The line to hold is simple: the work written specifically for you should be yours, and everything else should be something you are clearly and lawfully entitled to keep using. Ask for that distinction to be spelled out.

Escrow, and when it is actually worth it

Source code escrow is where a copy of the code is lodged with a neutral third party and released to you if certain things happen, typically the supplier going out of business or failing to meet support obligations. It is a reasonable safeguard for larger arrangements, particularly where you are licensing software rather than owning it outright.

For most bespoke projects at the SME scale, escrow is more ceremony than protection. If the contract already assigns you the copyright and you already hold the source in your own repository, there is nothing to escrow, because you have the code in your hands. Escrow earns its keep when the supplier retains ownership and you need a route to the code if they disappear. It is a poor substitute for owning the thing in the first place. The related worry, of being stranded by a departed developer, is the same one behind much legacy system replacement work, where the first task is often recovering a system nobody can safely change.

What to put in the contract

You do not need to be a lawyer to protect yourself here, but you do need a few things stated plainly before work starts:

That copyright in the bespoke code is assigned to you on payment, in writing. "On payment" is fair to both sides and common practice.

That you receive the source code and the repository, not just a running build.

That any third-party and open-source components are listed, with their licences, so you know what you are relying on.

That you get the credentials and access to host and run the system yourself, or to hand it to someone who can.

That there is no lock-in: nothing in the arrangement should stop you moving to another supplier or bringing the work in house.

None of this is exotic, and a straightforward supplier will not flinch at any of it. If a developer resists assigning ownership of work you have paid for in full, treat that as information.

A note, and where this fits

This is general information, not legal advice; for a specific contract, take proper advice on the wording. But the principle is sound and it should shape how you buy: ownership is decided by the paperwork, not by who paid the invoice, so settle it at the start rather than discovering it at the end.

Getting these terms right is part of why some businesses choose a bespoke build in the first place, rather than renting software they will never control. We go into that trade-off in bespoke software versus off-the-shelf, and the way we approach ownership and handover runs through all of our web and app development work. The price bands, and what moves a project up them, are on the bespoke software cost page.

If you are weighing up a project and want a straight answer on how ownership, source code and handover would work, get in touch. You should expect to own what you pay for, and it is reasonable to ask for that in writing.