If Your Developer Disappears, What Do You Actually Own?

The message nobody wants to send twice is "are you still there?" Sometimes it is a freelancer who took a full-time job and stopped answering. Sometimes it is a small agency that quietly folded. However it happens, the question that follows is the same, and it is usually asked in a panic: what do we actually own here?

The honest answer is often less than the owner assumed. Not because anyone set out to trap them, but because the legal default runs opposite to common sense, and because the practical details that decide the outcome are the ones nobody checked while the project was going well.

What follows is the UK position under one Act, and we are not lawyers. Treat it as what to ask about, not as advice on your own contract. Ownership defaults differ between countries and we have not checked any other country's rule, so if you are outside the UK, find out where your own law lands before you borrow anything from this.

Paying for code is not the same as owning it

Under the Copyright, Designs and Patents Act 1988, a computer program is a literary work. Section 3(1) defines literary work to include a computer program and, separately, preparatory design material for a computer program. That matters because of what section 11 then does with literary works.

Section 11(1) sets the general rule: "The author of a work is the first owner of any copyright in it, subject to the following provisions." The provision that matters commercially is section 11(2), and it is narrow. Where a literary work, among other kinds, "is made by an employee in the course of his employment", the employer becomes "the first owner of any copyright in the work subject to any agreement to the contrary". The rest of section 11 carves out Crown copyright, Parliamentary copyright and certain international organisations.

Read those together and the problem appears. Where an employee writes code in the course of the job, first ownership sits with the employer unless they agreed otherwise. Section 11(2) is written for employees, and a genuine contractor, freelancer or outside agency is not one, so the default in 11(1) stands and the author is the first owner. Whether a particular person counts as an employee turns on the real relationship rather than the label on the invoice, which is one more reason to have this checked rather than assumed. Payment settles a debt. It does not move copyright.

Section 90(3) closes the loop and is the sentence worth writing down: "An assignment of copyright is not effective unless it is in writing signed by or on behalf of the assignor." Not a handshake. Not a friendly line in an email. Not a bullet in the proposal deck that said "client owns all deliverables" if nobody signed the thing it was in. Without a written, signed assignment, whatever you have is not ownership. What is left to argue about is the scope of a licence, and that argument runs on your actual documents, which is lawyer territory. It is a much thinner thing to hold when you want to hire someone else to change the code.

What "you own it" has to mean on paper

The fix is not complicated and it costs nothing at the start of a project, which is why it is infuriating to discover you skipped it. You want a written assignment of copyright in the work, signed, naming your company as the owner, covering the source code and the preparatory material rather than just "the deliverables".

Two details are worth arguing about while everyone is still friendly. The first is whether the assignment is conditional on final payment. Developers often want that and it is a normal commercial term, but it belongs in writing rather than left ambiguous. The second is the developer's pre-existing components, the internal library they reuse on every project. They will usually not assign that, and they should not have to. What you need instead is a licence to keep using it, one that survives the relationship ending and does not require their cooperation to exercise.

If a supplier will not put an assignment in writing, that is information. It is not necessarily malice, and small suppliers often have never been asked. How they respond tells you most of what you need to know.

The things that must be in your name before the first commit

Ownership on paper is worthless if you cannot reach the thing you own. The failure worth preparing for is not a courtroom one. It is an ordinary Tuesday where the person who had the passwords is gone, and the code is technically yours in a repository you cannot log into.

The Git repository should live in your organisation, with your developer invited into it, and not the other way around.
The hosting and cloud accounts should be opened in your company name with your billing details, even if the supplier administers them day to day.
The domain and the DNS should sit in an account owned by you, because that is what takes a business offline fastest when it goes wrong.
Third-party API keys and licences should be registered to your company address, not to a developer's personal email.
Someone other than the author should have run the build and the deployment at least once from the written instructions, and confirmed they actually work.

That last one is the test that catches everything else. A build document nobody has followed is a guess. Ask for a handover session where somebody on your side deploys to staging while the developer watches and stays quiet.

Boring technology is a risk decision, not a taste decision

Every unusual framework choice narrows the pool of people who can pick the work up later. That is fine when it buys something real, and expensive when it was made because it was interesting. You do not need to assess the stack yourself. Ask one question and listen to the shape of the answer: if you disappeared, how easily could another developer take this over, and what would they struggle with?

A good supplier will answer that specifically, including the parts that are genuinely awkward. Anyone who says the question does not apply to them is telling you something useful.

Is software escrow worth paying for?

For most SMB custom builds, no, and it is worth being clear about why, because escrow gets recommended to people who do not need it.

Escrow exists for licensed software. You buy a product, the vendor keeps the source because it is their product, and escrow parks a copy with a neutral third party so you can reach it if the vendor goes under. It answers a real problem: you were never going to hold that source code, so someone else has to.

A bespoke build you commissioned is a different situation. You should already have the source, in your own repository, from the first commit. Paying a third party to hold a copy of something you already possess is solving a problem you fixed by other means. The published prices make that concrete, and both vendors quote in US dollars. Codekeeper lists its single plan at $139 a month per application billed annually, or $179 a month on monthly billing, each with a $249 setup fee. EscrowTech's fee table shows a $995 setup fee and $1,595 a year for a single beneficiary escrow agreement, plus $250 per release to a beneficiary. Those are fair prices for what they are. They also come to several thousand dollars over a few years, spent to insure against losing access to a repository you already control.

Escrow does earn its keep in the other direction. If you license a vendor's product that your operation depends on, and that vendor's survival is a real question, escrow is the right tool and you should ask for it. The distinction is whether the code was ever going to be in your hands.

What to ask before you sign anything

Ask who owns the copyright when the project ends, and ask to see the clause rather than being told about it. Ask what pre-existing components will be reused and what licence you get to them afterwards. Ask where the repository lives and whose account it belongs to, and whether the build instructions have ever been followed by someone who did not write them. Ask what would be hard for a new developer picking this up in two years.

None of that requires you to be technical, and none of it is an accusation. It is the same conversation as asking a builder whether the extension has planning permission. The suppliers worth working with will find it a relief.

We hand over the repository from day one, run on infrastructure the client owns, and put the assignment in writing. That is easy to say and easy to verify, so ask to see it. If you are weighing a build, our piece on what another SaaS seat really costs covers the money side, and if you run an agency rather than buy from one, white-label capacity against hiring a developer is the same question from the other side of the desk.

If you have an existing system and do not know what you own, that is common and fixable. Tell us what you have and we will tell you what is missing, whether or not you build anything with us. If you are scoping something new, the custom software page explains how we quote it.