Can a developer keep my code if I stop paying them?

If the contract makes the assignment conditional on full payment, then yes, the copyright stays with the developer until you have paid. That is a common and reasonable term. The risk is a contract that never assigns anything at all, or one that only promises to assign later. Check whether yours transfers rights at signature or at final invoice, and confirm which invoices are outstanding.

Do I need a source code escrow agreement?

Usually not for a custom build. Escrow exists for licensed products where the vendor holds the code and will not release it. If you commission software and own the repository from the first commit, you already have what escrow is meant to deliver, at no cost. Escrow makes more sense when you licence a platform from a vendor who will never hand over the source.

Who owns the data in a custom system, as opposed to the code?

The data is yours, and it is usually the more valuable half. Ownership of the records is separate from copyright in the software that reads them. Make sure your contract says so explicitly, that you can export the full dataset in a standard format on request, and that the agency deletes its copies when the work ends. Test the export before you need it.

What if my developer used open-source libraries in the build?

That is normal and not a problem, but the licences travel with the code. Permissive licences like MIT and Apache 2.0 ask little of you. Copyleft licences such as the GPL can carry conditions if you distribute the software. Ask for a dependency list with licences at handover, so you know what you are agreeing to before anyone ships it to a customer.

Who owns custom software code after you've paid for it?

Say you run a 20-person freight forwarder in Jebel Ali. Three years ago you paid an agency to build a client portal. It works, and your clients open it every morning. Now you want to move to a different developer, so you ask for the code.

A zip file arrives. No git history, a readme that says npm install, and an environment file full of keys belonging to somebody else's Amazon account.

Who owns custom software code is settled by two things: a signed assignment of copyright, and about eight account logins. Paying the invoice does neither. Under US and UK law the default is that the person who wrote the code owns it until they sign it over, and an assignment you can't act on is a piece of paper.

Do I own the code if I paid a developer to write it?

Not automatically, no. Copyright in a piece of software belongs to whoever wrote it, and a contractor isn't an employee. Money changing hands doesn't move a copyright. A signed document does.

Why "work made for hire" does not cover software

In the US, Circular 30 from the Copyright Office sets out four criteria a commissioned work has to clear before it counts as a work made for hire. There has to be a written agreement. The parties have to expressly agree the work is made for hire. Everyone signs. And the work has to fall inside one of nine categories listed in the statute (17 U.S.C. section 101, the definitions section of the US Copyright Act).

Here are the nine: a collective work, part of a motion picture or other audiovisual work, a translation, a supplementary work, a compilation, an instructional text, a test, answer material for a test, and an atlas.

Read it twice. Software isn't there. The Circular's own wording is blunt: a work that "fails to satisfy any of these requirements" is not a work made for hire.

So a clause saying "all deliverables shall be works made for hire" can be signed by everyone, notarised, and still leave the copyright sitting with the developer.

What moves it is an assignment, and the wording matters more than the length. "Developer hereby assigns" transfers the copyright at signature. "Developer agrees to assign" is a promise to do something later, worth exactly as much as their willingness to do it later. Ask a lawyer which verb is in yours.

The UK default runs the same way. The author owns the copyright, commissioning the work doesn't change that, and an assignment has to be in writing and signed by the person giving it up. An invoice marked paid isn't an assignment anywhere we work.

Who owns the accounts your custom software runs on?

Whoever's name is on the billing, and it usually isn't yours. Nobody audits this half, and it's the half that decides whether you can leave.

A small client portal touches more accounts than people expect. Work through them by name:

The Git host. The repository needs to sit in a GitHub or GitLab organisation your company owns, not the agency's.
The cloud or hosting account. AWS, Google Cloud, Azure, Vercel, Hetzner. Whose card is on it?
The database. A managed Postgres on Supabase or RDS sits inside someone's project, and that someone can delete it.
The domain and DNS (Domain Name System, the directory that points your domain at a server). Registrar login, nameservers, the lot.
Third-party API keys (Application Programming Interface keys, the credentials that let your system call another company's service). Stripe, Twilio, a mapping provider, an email sender. Each is an account with an owner.
The authentication provider, if the portal uses Auth0, Clerk or Cognito.
Deploy and CI (continuous integration, the pipeline that builds and ships each change), including GitHub Actions secrets and any deploy keys.
Error monitoring and analytics, because that's where the logs live.

Now the test. Not "can I get access if I ask", which is a question about goodwill. Can you log in right now, on your own, and add a user to the production database? If the honest answer involves emailing anyone, you don't control the system. You have a supplier who is currently being nice to you.

We'd apply the same test to any integration claim, and we've written about how to tell whether an integration is real rather than a screenshot. Ask to see the thing, in the account, with your own login.

A single lit route traced left to right through a dim network of account nodes, ending at one highlighted node, with the stages labelled contract, accounts and handover.

Who owns custom software code that AI helped write?

Parts of it may belong to nobody at all, which is a genuinely new problem. In January 2025 the US Copyright Office published Part 2 of its report on copyright and artificial intelligence, and the finding is narrow but sharp: outputs of generative AI can be protected by copyright "only where a human author has determined sufficient expressive elements".

The report is careful to say the opposite of what the panicky version of this claims. Using AI to help create something, or including AI-generated material inside a larger human-authored work, "does not bar copyrightability". A developer working with an assistant is still an author. A developer accepting whole files untouched is on thinner ground.

There's a paperwork consequence too. The Office's registration guidance puts a duty on applicants to disclose AI-generated content in anything they file, and to exclude from the claim any AI-generated material that's more than de minimis, meaning more than a trivial amount.

For a business commissioning a build in 2026, the practical version is short. An assignment clause can only transfer rights that exist. If a meaningful slice of your codebase was generated rather than written, that slice may carry no copyright for anyone to hand you, including your developer.

This doesn't stop you running the software, changing it or selling the business. It does weaken any plan that treats the code itself as an exclusive asset. Ask your developer how they use these tools and how output gets reviewed. A straight answer is a good sign.

What should a custom software handover include?

Everything needed to run the system without the people who built it. Run it as a list, in order, and don't accept a zip file:

The repository transferred into your organisation, with full commit history, branches and tags.
Owner-level access to every account above, with the agency downgraded to a member you can remove.
Billing moved onto your payment method, which proves ownership faster than any contract.
A running environment you can deploy to, plus the exact steps to deploy it.
A database export you have actually restored somewhere, not just received.
An architecture note explaining what talks to what, and which third parties would break the system if they went down.
The signed assignment, naming the work and using the present tense.
A list of every open-source licence the project depends on.

Point five is the one people skip. A backup nobody has restored is a hypothesis.

When owning the code is worth less than you think

Here's the part that costs us something. The arrangement we argue for, client-owned accounts from the first commit, removes the only real hold an agency has. A client set up that way can end the relationship on a Tuesday and be shipping with someone else on Wednesday. We think it's the right trade, because an agency that keeps clients by holding their keys has a retention problem it isn't fixing. It's still a cost, and pretending otherwise would be dishonest.

The second admission is worse for us. For a lot of small builds the source code isn't the valuable asset, and if you're paying a premium mainly to own it, you're buying the wrong thing.

A focused internal tool might be a few thousand lines of TypeScript wired to four APIs. A competent developer can rebuild that. What nobody can rebuild is four years of your data, your customers' logins, and the URL your clients have bookmarked.

Owning code you can't read is a liability as well as an asset. Dependencies need patching. Frameworks go out of support. A repository sitting in your GitHub organisation with nobody maintaining it isn't insurance, it's an unpatched service on the public internet with your name on it. Before you commission anything, check whether the job is really a build, or whether connecting the tools you already pay for gets you most of the way.

What changes for software ownership in the next two years

The rest of the Copyright Office's AI work is the first thing to watch. A pre-publication version of Part 3, covering generative AI training, went out on 9 May 2025, with a final version still to come. Contract language about AI-assisted development will get more specific as that lands. If you're signing a multi-year agreement now, ask for a clause that says who discloses what.

The second shift is cheaper exits from infrastructure. Google Cloud removed network data transfer fees for customers migrating off the platform on 11 January 2024, applying it globally, and the other large providers moved the same way. The bill for leaving is falling. What stays expensive is the part with no price list: an account in somebody else's name, a database you've never exported, a domain you can't point somewhere new.

Build for that. Assume you'll move the system at some point, and set it up so the move is boring.

What to do this week

Open a document. Write down every account your custom software touches, and next to each one write the email address that owns it. Twenty minutes, and the gaps will be obvious.

If more than two of those accounts sit outside your company, fix that before the next feature. We build internal tools, portals and dashboards client-owned by default, and we'll read an existing setup and tell you where it's held. Send us what you've got and we'll go through the list with you.