feliXart
All articles

Who should own the source code?

This question tends not to be asked while the relationship is going well. The moment it is asked is the moment the relationship has ended — and by then it is late to ask.

Published: 24 August 2026

The short answer

The short answer: if you paid for it, the source code should be yours. But the real issue is transferability rather than ownership — code you hold that nobody can run leaves the ownership on paper. What to look for in a contract is not the sentence “the code is ours” but the installation documentation, the infrastructure accounts and the handover procedure.

01

What is the difference between a software licence and ownership?

Many contracts say the client is granted a perpetual right of use. That is a licence, not ownership. You may use the software, but you cannot modify it, have another supplier develop it, and often cannot move it to another server.

The difference is invisible while the relationship lasts. It surfaces when the supplier raises prices, slows down or ceases trading. At that point you hold working software and can do nothing with it.

For business software built specifically for you and paid for by you, ownership is the natural arrangement. Licensing an existing product is a different transaction and is priced differently; conflating the two in one contract works against the buyer.

02

What should a software handover include?

Owning the source code is not sufficient on its own. If a new team receiving it cannot install and run it, the ownership does not function.

A transferable handover contains:

  • The complete source and its version history
  • A from-scratch installation document and the list of environment variables
  • Database schema, migrations and sample data
  • Ownership of infrastructure, domains, certificates and third-party accounts
  • The backup arrangement and the restore procedure
  • A written record of architectural decisions and known technical debt

The test for that list is simple: can your team, or another supplier, bring the system up from nothing without our help? If not, the handover is incomplete.

03

Third-party components and open-source licences

Every system contains components belonging to others: open-source libraries, a payment provider, a mapping service, a model provider. Those are not expected to be yours.

What should be expected is transparency: which component is used, under which licence, whether commercial use is restricted, and what replaces it if it disappears. That inventory belongs in the handover documents.

04

When is source code escrow needed?

Where source is not transferred to the client, it can be held by a neutral third party and released if the supplier ceases trading.

Escrow is a solution but a second-best one: it provides protection, not transferability. Escrowed code usually cannot be run either without installation documentation. Where ownership can be taken directly, escrow is unnecessary.

05

How is a source code clause written into a contract?

These clauses should be explicit: who owns the source, when it transfers, which documents the handover covers, in whose name infrastructure accounts are opened, and within what period handover completes when the contract ends.

One further clause matters more and is often skipped: does the handover hold in the scenario where the relationship ends badly? In a good parting everyone helps; a contract is written for a bad one.

In the systems we build the source belongs to the client and the system runs on the client’s own servers. We treat that not as generosity but as an arrangement protecting the buyer’s negotiating position: continuing to work with us should be a choice rather than a necessity.

Frequently asked

Why would a supplier agree to us owning the code?

It is a reasonable request and it is reflected in the price. A supplier’s income should come from the work rather than from keeping a client locked in. Where a supplier refuses, the reason is worth asking about.

We own the code — who maintains it?

Ownership does not end the relationship. Most clients continue with the same team for maintenance and development after taking the code; the difference is that it is now a choice.

Does this apply to cloud services?

Partly. Code we wrote transfers; a cloud provider’s services do not. That is why accounts should be opened in the client’s name and the system built so it can move to another provider.


Let’s talk about where you are.

Tell us what you want to build — and we will say so plainly if you do not need it.