Who Owns the Code When You Hire a Software Company?

Most people assume that when they pay an agency to build software, they own the result. It feels obvious. You wrote the cheque, so it is yours. Then a year later you want to move to a different team, or bring the work in-house, and you ask for the repository. That is often the moment you find out the contract never actually said the code was yours, and the studio that built it is under no obligation to hand it over.

Ownership is the clause almost nobody reads before signing and almost everybody regrets afterward. It rarely matters while the relationship is good. It matters enormously the day it ends. This is a plain guide to how source-code and intellectual-property ownership really work when you hire a software company, and the specific things a contract needs to say so the thing you paid to build is genuinely yours.

"We paid for it" is not the same as "we own it"

Paying for a service and owning its output are two different things in law, and software sits on the wrong side of that line by default in a lot of jurisdictions. Copyright in code generally belongs to the author, the person or company that wrote it, unless a contract transfers it. An agency you commission is usually an independent contractor, not your employee, so the automatic "work made for hire" rules that hand an employer the rights to an employee's output often do not apply cleanly to an outside vendor.

That means the default, in the absence of an explicit assignment, can be uncomfortable: the studio owns the copyright to the code it wrote, and you have a licence to use it. Sometimes that licence is broad and perpetual. Sometimes it is narrow, tied to their continued involvement, or silent on whether you can hand the code to someone else. You do not want to discover which one you have during a divorce.

The four things a contract should actually assign

"You own everything" is a nice sentence in a sales call and a useless one in a contract. Ownership breaks into distinct pieces, and a good agreement is explicit about each.

• The source code. A present, written assignment of copyright in the custom code, effective on payment, plus the deliverable itself: the actual repository, not a compiled build. "You will receive the software" is not "you will receive the source code."
• The wider IP. Designs, database schemas, architecture, documentation, and any patentable methods created specifically for you. These travel with the code or they do not, so name them.
• Your data. Obvious, but spell it out anyway: the data your users and your business generate is yours, exportable in a usable format, and not held hostage.
• Third-party and pre-existing components. No custom project is 100% original. Open-source libraries come with their own licences, and any reusable framework or internal tooling the agency brings stays theirs. A fair contract grants you a perpetual, transferable licence to those pre-existing pieces so the whole thing keeps working after they leave.

That last point trips people up. It is normal and fine for an agency to reuse its own internal libraries; you should not expect to own their toolkit. What you should insist on is a licence broad enough that removing the agency never breaks the product.

Source-code escrow, repositories, and the bus factor

Owning the code on paper means little if you cannot actually get it. Three practical safeguards turn a clause into something real.

First, insist the code lives somewhere you control from day one: a Git repository under your organisation's account, with the agency added as collaborators, rather than a repo on their infrastructure that you request access to later. Access on day one costs nothing and prevents the most common handover fight.

Second, for larger or business-critical builds, consider a source-code escrow arrangement, where a neutral third party holds a current copy of the code and releases it to you if the vendor goes bust, stops maintaining it, or breaches the contract. It is a well-established mechanism for exactly the "what if they disappear" fear.

Third, ask about the bus factor: how many people understand this system well enough to keep it running? Owning code you cannot read or deploy is a hollow victory. Documentation, a working local setup, and deployment instructions are part of the deliverable, not a favour.

AI-generated code is a new grey area

A large share of code written in 2026 is produced with AI assistants, and that complicates ownership in ways a 2020 contract never anticipated. Two questions matter.

Can AI-generated output be owned at all? In several jurisdictions, purely machine-generated work with no meaningful human authorship may not attract copyright, which sounds fine until you realise it can also mean nobody can stop a competitor from copying it. In practice, the code your agency ships is a mix of human and AI work, and the human editing usually carries enough authorship, but the edges are genuinely unsettled.

The sharper risk is provenance. AI tools can reproduce snippets from their training data, some of it under restrictive licences. A responsible studio uses tooling to flag that and can tell you how the code was produced. Ask. A clause warranting that the delivered code does not knowingly infringe third-party rights, AI-assisted or not, is worth having. We wrote more about the downstream cost of unmanaged AI code in AI-generated code and technical debt.

What to ask before you sign

You do not need to be a lawyer to protect yourself. You need to ask five questions and get them answered in writing.

1. On final payment, is copyright in the custom code assigned to us in full? Assigned, not licensed. Get the word "assign" in the document.
2. Do we get the source code and the repository, with documentation and deployment instructions? And can we host the repo ourselves from the start?
3. What pre-existing or open-source components are involved, and what licence do we have to keep using them forever, even without you?
4. Is our data ours, and can we export it in a standard format on request?
5. What happens on exit? A clean, defined offboarding, code, credentials, accounts, handover, beats a vague promise every time.

None of this signals distrust. The best studios volunteer these answers before you ask, because clear ownership is a sign of a healthy engagement, not a hostile one. If a vendor gets defensive when you raise ownership, that is the answer to a different question. For the wider set of things to vet in a partner, see how to choose a software development partner, and if you are still scoping the work, how to scope a custom software project.

Software is one of the few things you can pay full price for and still not own. A few sentences in the contract are the difference between a product you control and one you rent without knowing it.