Guide · Hiring, contracts & ownership

Who owns the code? A founder's checklist before you pay any developer, including for AI-written code

Who owns the code when you hire a developer or agency, or when AI writes it? A founder's checklist for contracts, repos, cloud and app-store accounts.

By Akash Bansal, founding engineerUpdated 4 November 20266 min read

"Who owns the code?" sounds like a legal question. In practice it's two questions: who owns it on paper, and who controls it on a Tuesday afternoon when something breaks. Founders get burned when the answers are different. Here's the checklist I'd want a friend to use before paying any developer, me included. I'm an engineer, not a lawyer, so treat this as a list of things to check and ask a lawyer about, not legal advice.

Who owns the code when you hire a developer or agency?

Whoever the contract says, and if the contract says nothing, usually the person who wrote it. In the US, copyright starts with the author. For an employee, the employer owns work done in the job. For a contractor or agency, it's more limited: work is "made for hire" only if it fits one of nine categories listed in the law and there's a signed agreement saying so (US Copyright Office, Circular 30). Software isn't clearly one of those categories.

So a contract that only says "this is work for hire" can fail for code. The fix is an explicit, signed assignment of copyright from the developer to your company, which US law requires to be in writing (17 U.S.C. § 204). Most contracts that handle this well include both: a work-for-hire clause, and a backup assignment in case the first doesn't apply.

Other countries have their own defaults, and many also expect a written assignment for contractors. If your company or your developer is outside the US, ask a local lawyer how it works there.

Legal ownership vs practical control

Owning the copyright doesn't help if someone else holds the keys. The contract decides who owns the code; the accounts decide who can use it. You need both.

If any of these is already in a developer's name, it can usually be moved. GitHub, for example, lets an owner transfer a repository to another account or organization (GitHub Docs). But moving needs their cooperation. It's much easier to start in your name than to ask for it back during a dispute. Investors and acquirers check the same items in a technical due diligence review, so it pays to fix them before anyone asks.

The founder's checklist: before, during and after the build

Before you pay anything

1. The contract assigns all rights in the work to your company, in writing, with a backup assignment if work-for-hire doesn't apply.
2. It says when ownership transfers. "On full payment" is common; "as created" or "per milestone paid" protects you better if things end early.
3. It lists any pre-existing code or tools the developer will reuse, and gives you a permanent licence to use them in your product.
4. It requires the developer to tell you about open-source components and their licences.
5. It names the people who'll do the work, if that's why you're hiring them.
6. A lawyer has read it.

On day one

1. You create the repository, cloud, domain, app-store and payment accounts in your company's name, or the developer creates them with you while you watch.
2. You are the owner or admin on each; the developer is a member.
3. Passwords and keys live in a password manager you control.

During the build

1. Code is pushed to your repository at least weekly. You can see the history.
2. You see a working demo regularly. Code you can't run is hard to call yours.
3. Important decisions are written down in your workspace.

At handover

1. Documentation explains how to run, deploy and change the product.
2. Someone other than the original developer can deploy it from the docs.
3. You remove the developer's access, or reduce it, when the engagement ends.

Who owns code written by AI, like Claude, ChatGPT or Copilot?

There are two layers. Between you and the AI vendor, the terms usually give you the output. Whether anyone can own copyright in it depends on how much of it a human wrote.

• The vendor's terms. Anthropic's commercial terms say the customer owns its outputs, and Anthropic assigns its rights in them to the customer (Anthropic). OpenAI's terms say you own the output and assign OpenAI's rights, if any, to you (OpenAI). Check the terms for the plan you're actually on; consumer and business terms differ.
• Copyright itself. The US Copyright Office's January 2025 report says copyright requires human authorship, that prompts alone aren't enough, and that human-authored work made with AI assistance can be protected, case by case (US Copyright Office). In Thaler v. Perlmutter, the D.C. Circuit held in March 2025 that a machine can't be an author under the Copyright Act, and the Supreme Court declined to hear the appeal in March 2026 (SCOTUSblog).

What this means for a founder, practically:

1. Your contract still matters most. If a developer or agency uses AI tools, the contract should still assign everything they deliver to you, and the developer should still be responsible for it.
2. Human work is what's protectable. Code a person designs, reviews, rewrites and integrates is on stronger ground than code pasted straight from a prompt.
3. Keep the repository private. Whatever copyright covers, a private codebase plus confidentiality terms is what stops copying in practice.
4. Watch licences. AI tools can reproduce snippets from open-source code. Running a licence check is cheap.

If your app was built mostly with an AI tool and you're unsure what you have, I cover what to check in rescue, rebuild or keep prompting.

What are the red flags?

• "We'll host it for you" on the agency's account, with no plan to move it.
• "You'll get the code at the end of the project."
• The repository lives in the agency's GitHub organization and you've never been invited.
• The app-store listing or payment account is in the developer's name.
• No written IP clause, or one that gives you only a licence.
• Reluctance to name the open-source and third-party components used.

Any one of these can have an innocent explanation. Ask about it before you pay, not after. Several of them sit behind the agency stories in why founders waste $50K on agencies.

What if your developer already holds your code?

Ask calmly, in writing, and in order. Most handovers go fine when they're requested early and politely; they get hard when they start as a fight.

1. Read the contract. Find the IP clause and any condition, such as payment of the final invoice.
2. Make a list of every asset in the table above and where each one sits today.
3. Ask for access, not files. Request that the repository and accounts be transferred to your company's organization, rather than a zip of the code. A zip leaves out history, settings and secrets.
4. Move the accounts with the most leverage first: domain, payments, app stores, then cloud and repository.
5. Rotate every password and key once the transfer is done.
6. Have someone else deploy it. If another engineer can't run the product from what you received, the handover isn't finished.

If the contract gives you only a licence, or the developer refuses, stop and talk to a lawyer before you escalate.

How I set it up on my builds

You own everything from the first commit. The code lives in a repository in your name. The cloud, domain, app-store and payment accounts are yours, and I'm added as a collaborator. Decisions are written down in design docs, so nothing lives only in my head. If we stop working together, nothing has to be transferred or negotiated, because it was never mine. The exit is free.

I set it up that way because it's the only arrangement where you don't have to trust me to get your product back. You already have it. If you want a build that starts like this, here's how I work. And whoever you hire, run this checklist first.