Who owns the code when an agency builds it?

This is the question buyers most often forget to ask and most regret not asking. The default in many jurisdictions is that the party who wrote the code owns it, not the party who paid for it — unless the contract says otherwise.

Get ownership in writing

The contract should assign intellectual property in the delivered work to you, on payment. Not a licence to use it; ownership.

A supplier who hesitates here is telling you something important about their business model. There are legitimate exceptions — a firm's pre-existing internal libraries are reasonably licensed rather than assigned — but those should be named explicitly, not left vague.

Ownership is useless without access

Owning code you cannot reach is a technicality. Four things should be in your name and under your control from day one:

• The git repository, in your organisation, with the supplier added as a collaborator.
• The domain registrar account.
• Hosting, database and any cloud provider accounts.
• Every third-party service the product depends on — payment, email, analytics, maps.

Suppliers often set these up on their own accounts because it is faster. It is faster. It also means a difficult separation becomes an impossible one.

The exit test

Ask directly: if we parted ways tomorrow, what would another team need to pick this up?

A confident supplier answers comfortably, because the answer is "the repo and the README". A supplier whose business depends on you being unable to leave will produce a less direct answer, and that is the signal.

Documentation is part of the deliverable

Not a manual nobody reads. Specifically:

1. How to run it locally, from a clean machine.
2. How to deploy it, and what to do when a deploy fails.
3. What external services it depends on and where those credentials live.
4. The decisions that would otherwise look arbitrary, and why they were made.

That last one is the difference between inheriting a codebase and inheriting an archaeology project.

What about open source?

Nearly every project includes open-source dependencies, and their licences do not transfer to you — they govern your use. This is normal and not a problem, provided the licences are compatible with how you intend to use the product.

Worth asking for a dependency list with licences at handover, particularly if you may later sell the business or the software.

More on evaluating a supplier in how to choose a development partner, and the brief that starts the conversation on the right footing in our brief builder.

Who owns software an agency builds for us?

It depends entirely on the contract. In many jurisdictions the default is that the party who wrote the code owns it, not the party who paid for it, unless the agreement assigns it otherwise. Your contract should assign intellectual property in the delivered work to you on payment — ownership, not a licence to use it.

What should we hold in our own accounts?

The git repository, the domain registrar, hosting and database accounts, and every third-party service the product depends on. Suppliers often create these on their own accounts because it is faster, and it is — but it turns a difficult separation into an impossible one.