Who Actually Owns Your Business Software? The Question Most Businesses Don't Ask

Most UK businesses that commission bespoke software assume they own what they have paid for. Often they do not. The question of software ownership — who holds the intellectual property rights, who has access to the source code, who controls the future of the system — is one that rarely gets asked clearly before work begins. It almost always matters when something goes wrong.

The Three Models of Software Ownership

When a business commissions software development, one of three ownership arrangements typically applies — though they are not always stated explicitly in the contract.

The developer retains the IP. This is more common than most clients realise, particularly with agencies. The developer builds the software, the client pays for it, but the underlying intellectual property — including the source code — remains the developer's. The client receives a licence to use the software, often tied to a continued relationship or ongoing payment. If the relationship ends, so may the licence.

The client owns the executable, not the source. A step better, but still significantly limited. The client can run the software and deploy it, but cannot modify it, fix bugs in it, or develop it further without returning to the original developer. There is no portability and no independence.

Full assignment to the client. All intellectual property transfers to the client upon completion and payment. Source code, database schemas, documentation, build scripts — everything. The client can take the software to any developer, modify it themselves, fork it, or archive it. This is genuine ownership.

The distinction matters most at the moments when business relationships change: when a developer retires, when an agency closes, when a relationship breaks down, or simply when you want to bring in a different developer to add a feature. The first two models leave you dependent; the third leaves you free.

What Genuine Ownership Looks Like in Practice

For every client I work with — NT Labs, Buxted Construction, Dugard, Ford Aviation — the source code lives in a GitHub repository owned by the client's own organisation. Not my GitHub. Not a shared account. Their account, under their control, from day one of the project.

This means that if I were hit by a bus tomorrow, every client could open their repository, hand the code to another .NET developer, and continue. There is no dependency on my continued existence or cooperation. The software is their asset, not my leverage.

It also means that when I am working on a project — adding features, fixing bugs, building new modules — the client can see exactly what is being done, when, and why. The commit history is transparent. There are no proprietary black boxes.

This is not the standard arrangement in the industry. It is a deliberate position, grounded in the belief that a client relationship built on dependency is not a healthy one. If a client stays because they want to, not because they have to, the relationship is better for both sides. This is part of why client relationships last decades rather than years.

What to Check in Your Current Arrangements

If you have bespoke software already — built by an agency, a freelancer, or an in-house developer who has since left — it is worth establishing clearly what you actually have.

First, find the contract. Look for language around "intellectual property", "IP assignment", "source code", and "licence". If it says "licence to use" and nothing about assignment, you probably do not own the software in any meaningful sense.

Second, establish where the source code is. If your developer has it on their systems and you do not have a copy, you are dependent on their goodwill. Request access and a copy. A developer who resists this request is telling you something important about how they view the relationship.

Third, check whether the code is documented and readable. Source code you technically own but cannot understand is of limited value. A well-structured .NET codebase with sensible naming and clear architecture can be handed to any competent developer. A maze of undocumented workarounds cannot.

The SaaS Question

Software-as-a-Service is a separate category entirely. With SaaS — whether that is a CRM, an ERP, an inventory system, or a project management tool — you own nothing. You are renting access. The software runs on the vendor's servers, your data sits in their database, and the terms of your access can change with notice (or sometimes without it).

This is not necessarily wrong. SaaS is appropriate for many business needs, and the trade-off — lower upfront cost, vendor-managed infrastructure, continuous updates — is a reasonable one for general-purpose tools.

The problem arises when a business's core operational processes become dependent on a SaaS product without understanding what happens if that product changes. Vendors raise prices. Products get acquired and sunseted. Features get removed. APIs get deprecated. Businesses that have built workflows around a SaaS product with no data export capability and no alternative have no negotiating position.

The question of vendor lock-in is closely related to ownership — and worth examining separately for any business that relies heavily on third-party software.

The Practical Conversation to Have Before Signing

Before commissioning any bespoke software development, three questions should be settled in writing:

Who will own the intellectual property on completion? The answer should be "the client, upon final payment", with a formal IP assignment clause in the contract.

Where will the source code be stored, and who will have access? The answer should be "in a repository owned by the client, accessible to the client at all times."

What happens to the source code if this relationship ends? The answer should be "nothing — the client already has it."

The cost of getting this wrong is not apparent when things are working well. It becomes apparent when you need to change something, when the developer is unavailable, or when a relationship breaks down. At that point, the difference between owning your software and being licensed to use someone else's becomes very concrete.

Bespoke software, done properly, is a business asset — something with genuine value, portability, and independence. Understanding what you are getting before you commission it is the most important part of the process. If you are considering a custom software project and want to understand what genuine ownership would look like for your situation, get in touch.

Frequently Asked Questions

What should a software ownership clause actually say?

It should state explicitly that all intellectual property rights in the software — including source code, design documents, and database schemas — transfer to the client upon final payment. 'Licence to use' is not ownership. If the contract doesn't say 'IP assignment', assume you don't own it.

Does it matter if I don't have the source code?

Yes, significantly. Without source code you cannot fix bugs independently, add features without returning to the original developer, or migrate to a different technology. You are entirely dependent on the original developer continuing to exist and choosing to work with you. Source code in your possession and in your control is the only genuine form of software ownership.

What happens to my software if the developer stops trading?

If you own the source code and it is in your own repository, nothing changes — you can take it to any developer. If you only have a compiled executable and the developer closes, you have a system you cannot modify and may not even be able to reinstall on new hardware. This is a business continuity risk that most businesses only discover after the fact.

Can I take bespoke software to a different developer?

If you own the source code: yes, straightforwardly. A competent .NET developer can read your C# codebase and continue development. If you only have the executable: no. If the code is in the original developer's repository and they hold the licence: only if they choose to cooperate. Ownership makes the difference between having an asset and having a dependency.

Is SaaS ownership different from bespoke?

Entirely different. With SaaS you own nothing — you are renting access to software running on someone else's servers, storing your data in their database. If the SaaS vendor shuts down, raises prices, or changes terms, your options are limited. Bespoke software with proper IP assignment gives you an asset that belongs to your business, independent of any third party's commercial decisions.

What should a software contract say about intellectual property?

The contract should include an explicit IP assignment clause stating that all intellectual property rights in the software — source code, database schemas, design documents, and build scripts — transfer to the client upon final payment. 'Licence to use' is not the same as ownership. If the contract uses the word 'licence' rather than 'assign' or 'transfer', assume you do not own it and ask for the clause to be changed before signing.

What does it mean to have source code in your own GitHub repository?

It means the code lives in a repository under your GitHub organisation — not the developer's. You have full access at all times, can see every commit and change, and retain control regardless of what happens to the developer relationship. Any competent developer you bring in later can be granted access immediately. There is no handover process required, no negotiation about what you are entitled to. It is simply yours, from day one.

How do I check what I actually own if I already have bespoke software?

Find the original contract and look for intellectual property language — specifically 'IP assignment' or 'transfer of rights'. If it says 'licence to use', you probably do not own the underlying software. Then establish where the source code is: if it is only on the developer's systems, request a copy. A developer who resists providing source code to a client who has paid for their system is signalling a dependency arrangement, not a partnership.

What are the three models of software ownership and which is best?

The first model is developer-retains-IP: the developer builds the software but keeps the intellectual property; the client receives a licence to use it, often tied to an ongoing relationship. The second model is client owns the executable but not the source: the client can run and deploy the software but cannot modify or maintain it independently. The third and only genuinely good model is full assignment: all IP transfers to the client on final payment, with source code in a client-owned repository from day one. The first two models create dependency; the third creates an asset.

How do I get started with a bespoke software project where I own the result?

The first step is a conversation about what you need built and what your current systems do. Every project I take on includes a full IP assignment clause — source code in your repository from day one, no questions asked. You'll get an honest assessment of whether bespoke is the right answer for your situation and what a realistic project would look like. Get in touch to start the conversation.