A business pays to replace a spreadsheet-heavy process with a tailored system. It is built around its own rules, customers and workflows. Then, months later, the relationship with the developer ends. The question becomes urgent: who owns custom software?

For most businesses, the answer should be clear before any development work starts. Yet it is often buried in a proposal, assumed rather than agreed, or confused with access to the finished system. Owning software, having a licence to use it, and having the practical ability to keep it running are three different things.

This is not a reason to make a straightforward project complicated. It is a reason to deal with a valuable business asset properly. A well-written agreement protects both sides and avoids an expensive argument at exactly the wrong time.

Who owns custom software under UK law?

Under UK copyright law, the starting position is usually that the person or business that creates the code owns the copyright in it. Paying for custom development does not, by itself, automatically transfer ownership to the client.

There is an important exception where software is created by an employee in the course of their employment. In that case, the employer will generally own the work. But an independent developer, consultant or agency is not normally an employee. Without a contractual assignment, they may retain the intellectual property rights even though the client has paid the invoice in full.

That can sound counterintuitive. The business may have provided the idea, process knowledge, data and requirements, while the developer has written the code. Legally, those contributions need to be separated and addressed in the agreement.

For a growing business investing in a system central to operations, relying on assumptions is not sensible. If ownership is part of the deal, the contract should say so plainly.

Ownership is not the same as a right to use

A licence can give a business broad rights to use a system without transferring the underlying copyright. That may be perfectly suitable in some circumstances. For example, a developer may retain ownership of a reusable framework, while granting the client a permanent, royalty-free licence to use the tailored application built on it.

The key question is whether the licence gives the business enough control. Can it continue using the software indefinitely? Can another developer maintain, alter or host it? Can it make copies for backup and disaster recovery? Does use depend on an ongoing support arrangement or a monthly fee?

A narrow licence may work for a non-critical tool. It is much less attractive where the system runs bookings, quoting, production, field work, compliance, customer records or finance processes. If changing supplier would leave the business unable to operate, the commercial risk is obvious.

What should a fair software ownership agreement cover?

There is no single answer that suits every project. A simple internal tool is different from a platform containing reusable technology developed over many years. What matters is being specific about what is being transferred, what is being licensed, and what happens once the work is complete.

For bespoke development, the agreement should normally deal with the following areas:

• Project-specific code and documentation: State whether copyright in the newly written code, configuration, designs and technical documentation is assigned to the client once fees are paid.
• Pre-existing tools and components: A developer may use templates, libraries, frameworks or utilities created before the project. These are often licensed rather than assigned, because they are reused across projects.
• Third-party software: Services such as cloud hosting, payment providers, mapping tools, email platforms and open-source packages have their own terms. Neither party can transfer ownership of something they do not own.
• Business data: Customer, operational and transaction data should remain the client’s property. The agreement should also cover how it can be exported when needed.
• Access and handover: The client should have access to source code, hosting accounts, domains, repositories, credentials and relevant documentation, not just a login to the finished system.

These points are not legal decoration. They determine whether the business can make a practical change in future without rebuilding everything from scratch.

Assignment versus licence: choosing the right model

An assignment transfers intellectual property ownership. For it to be effective in the UK, it needs to be in writing and signed by the person assigning the rights. It should identify what is being assigned and when the transfer takes effect, commonly on payment of all outstanding project fees.

A licence leaves ownership with the developer but sets out the client’s permitted use. It can be exclusive or non-exclusive, perpetual or time-limited, transferable or restricted. Those details matter far more than the label on the document.

For many bespoke business systems, a sensible middle ground is to assign the client-specific work while licensing reusable, pre-existing components on terms that do not obstruct normal use or future maintenance. This recognises the developer’s existing intellectual property without leaving the client dependent on one supplier.

There are also projects where a licence is the better option. If the work is built from a mature product platform that the developer supports for several clients, full ownership may not be available or commercially necessary. In that case, the client should focus on continuity: a long-term licence, clear service terms, data portability and a practical exit route.

The wrong approach is promising “full ownership” without defining it. That phrase can create confidence while leaving unanswered questions about source code, third-party services, database structure and the right to appoint another developer.

Do not overlook the practical controls

A contract is essential, but it is only part of the answer. A business that owns code but cannot access the hosting account, domain name, source repository or administrator credentials still has a problem.

Set up key third-party accounts in the business’s own name where practical. That commonly includes the domain, cloud hosting, email delivery service, payment account and source-code repository. A developer can be given the access needed to build and support the system without becoming the sole account holder.

Keep a simple record of what exists and where it is held. It does not need to be a large technical manual. At minimum, the business should know where the code is stored, how the system is hosted, which external services it relies on, who has administrative access and how data can be exported.

Documentation deserves similar common sense. No small business needs hundreds of pages of diagrams that no one reads. It does need enough information for a competent new supplier to understand the setup, deploy changes and deal with a fault without guesswork.

Questions to ask before development begins

Bring up ownership during the proposal stage, not after the system has become business-critical. A capable developer should be comfortable explaining their position in plain English.

Ask whether the client-specific source code will be assigned or licensed, what pre-existing components are excluded, and whether those components can be used and maintained by another supplier. Ask who owns the hosting, domain and third-party accounts. Confirm what handover material will be supplied and whether source code access is available throughout the project or only at completion.

It is also worth asking what happens if the project stops early. The answer may depend on how much has been paid and what stage the work has reached, but the principle should be agreed in advance. Clear milestone payments and a clear position on work completed reduce the scope for disagreement.

For larger investments or systems handling sensitive information, it is sensible to have a solicitor review the terms. This is not about mistrusting the developer. It is about ensuring that an operational asset is protected in a way that matches its importance to the business.

A good arrangement protects both sides

Developers are entitled to protect reusable methods, tools and software they created before a client came along. Clients are entitled to control the bespoke system they have funded and rely on to run their business. These positions are not in conflict when the scope is written properly.

The best projects start with direct conversations about processes, responsibilities and future support, then put the agreed position into clear terms. If a system is meant to remove operational bottlenecks for years to come, its ownership and handover arrangements should be just as practical as the system itself.