Who owns the software you paid for

When you pay for custom software, "you own it" sounds like one thing. In practice it is five things, and a contract that names only one of them leaves the other four to goodwill. This piece lists the five, shows how our own agreement handles the awkward one, and gives you two sentences you can put in front of any supplier.

What ownership splits into

Ownership splits into parts that can each end up in different hands:

• The source codeThe human-readable version of the software, the thing a developer needs in order to change it.: without it, nobody but the original supplier can change the product.
• Your data: everything the system holds about your customers, patients or orders, and the ability to export it at any time in a format another system can read.
• Accounts and domains: the domain name, hosting, app store and third-party service accounts, registered in your name rather than the supplier's.
• Documentation: how to run, deploy, back up and change it, written for the next person.
• The supplier's reusable platform: libraries, templates and tooling built before you arrived and used for other customers too.

Each of these can be yours, theirs or nobody's. A contract that says "the client owns the software" without naming them has decided the first and left the rest open. That is where most ownership disputes start: everyone agreed, and nobody agreed on what.

The deliverable and the platform are two different things

Most suppliers, including us, do not write every project from a blank page. Part of what you receive was built for you; part is a platform the supplier reuses. A fair contract names that split.

Our own agreement handles it this way. You own the project-specific deliverables that are identified in the scope, once they are paid for. We keep what existed before your project and what we reuse across projects: libraries, templates, deployment tooling and methods. Where those reusable parts are embedded in your deliverable, you get a non-exclusive, perpetual licenceNon-exclusive: the supplier may keep using the same material for others. Perpetual: the licence does not expire when the engagement ends. to use them as part of it, for your own internal use.

Two things follow. You cannot lift our platform out of your product and sell it on, and we cannot take your project-specific work and hand it to someone else. One thing is easy to miss: having the repository or the hosting under your control is not the same as owning what is in it. Our agreement says so in plain words: custody of hosting, deployment or repositories does not by itself transfer ownership. Ask any supplier where their line sits, in writing.

What handover must include

Ownership on paper is worth little if nothing arrives. A handover you can actually use contains:

• Access and ownership transferred: accounts, domains, credentials and billing moved to you, nothing left on the supplier's side.
• The source code, with the instructions to build and deploy it on infrastructure you control.
• A runbook for the routine work: deploying, backups, monitoring, updating a dependency.
• The decision log: why the system is shaped the way it is, so the next developer changes it deliberately.
• Open ends, named: the shortcuts taken knowingly and what would come next.

The test: could another developer take over from the handover alone, without calling the supplier? That needs the handover described and priced in the contract, not left as a favour for later. We scope the handover from day one for that reason.

If the supplier disappears

Companies stop, get sold, or drop a product line. Nobody can promise otherwise, so ask before you sign:

• What happens to the code and the data if the company stops, is sold or drops this product line?
• Can you reach the code without their cooperation?
• Could another party continue the work without rebuilding from scratch?
• What is the exit arrangement: notice period, final handover, cost?

We have no standard escrow arrangement to point at, so you will not find one in our agreement. What you will find is the ownership split above, the handover in the scope, and accounts in your name.

Two sentences for the contract

You do not need legal language to be clear. Two sentences in plain words do most of the work:

1. "The client owns the source code, data, documentation and project-specific deliverables listed in the scope, subject to payment. The supplier keeps its pre-existing and reusable materials and grants the client a perpetual, non-exclusive licence to use them as part of the deliverable."
2. "The domain name, hosting and third-party accounts are registered in the client's name. At the end of the engagement the supplier hands over source code, credentials, deployment instructions and documentation within the agreed period, at the price stated in this agreement."

This is not legal advice, and your adviser may sharpen the wording; it covers the two places where a software contract most often stays vague. Our general terms say that consultancy is an obligation of means and that the concrete arrangements on scope, pricing, acceptance and intellectual property live in the project documents, which is where these sentences belong.

A custom build is not a purchase, it is ownership. Ownership only means something when each part has a name on it. This is how we write our own agreements, and it is a fair way to read anyone else's.