Does the client own the code because they paid for it?

Only if the contract says so. In most jurisdictions copyright starts with whoever wrote the code, and it moves to the client through a written assignment or a work-for-hire clause. A lot of agency contracts have one. A surprising number do not, and an invoice on its own transfers nothing. Read the contract before you assume either way.

Can I reuse code I wrote for one client on the next?

Reuse what you kept the rights to. Generic components, libraries and tooling you built for yourself and licensed to the client are yours to reuse. Code you assigned to a client is theirs, even if you would write it the same way again. Agencies that expect to reuse work put a carve-out for their own tooling into every contract.

How long should we keep old client repositories?

As long as the contract or the law requires, and no longer. Some contracts oblige you to delete on handover; some client industries require you to keep records for years. Absent either, a fixed retention period after the engagement ends, written into your policy, is easier to defend than a drive full of things you meant to sort.

Is licensing code to AI labs safe for client confidentiality?

Only if none of the client's code goes in, which is a rule of the program rather than a courtesy: client-owned work is excluded, and you warrant that everything submitted is yours. Secrets and personal data are stripped from the review copy, but that is a backstop. The safety comes from only submitting repositories you own outright.

What should an agency do with old client code?

First work out what you actually own, because most of it belongs to the client. Then sort the repositories into three piles: delete what you were paid to hand over, keep what you built for yourself, and untangle anything mixed. The second pile has a market now: AI labs license private, agency-owned code, non-exclusively.

Who owns it

The belief that the client owns the code because they paid for it is common and usually wrong as a default. In most jurisdictions copyright starts with the author, which is the agency or its employees, and moves to the client only through a written assignment or a work-for-hire clause in the contract. Well-drafted agency contracts have one. Plenty do not, and an invoice is not an assignment.

That cuts both ways. If you assigned the IP, the code is the client’s however much you would like to reuse it. If you did not, you own more than you think, and a reasonable client will still expect to keep using what they paid for, so the honest position is that they hold a license and you hold the copyright. Read every contract before you sort anything, and if the contract is silent, treat the deliverable as the client’s and the tooling around it as yours. That is what a court is likely to do, and it is what keeps the relationship.

The three piles

Client-owned. The application, the site, the integration you were hired to build and assigned. Handover means handover: the repository in their account, the credentials rotated into their names, your copies deleted after whatever retention period the contract or their industry requires. A drive full of former clients’ code is a liability, and in some sectors a breach waiting to be reported.

Yours. Internal tools. R&D that never shipped. The prototype that lost the pitch. Shelved products. Libraries and boilerplate you carried from project to project under a license. This is the pile that has value beyond the original engagement, and the one most agencies leave to rot.

Mixed. A repository with your framework and their business logic in the same tree. These need either a careful split or a decision to leave them alone. Do not license a mixed repository on the theory that most of it is yours.

The AI-specific version of the question

Automation work creates a fourth kind of asset that the old contracts never anticipated. A delivered n8n workflow runs on credentials: whose account holds them after handover, and what happens to your access? The prompts inside it took weeks to tune: are they a deliverable, or your tooling? And a workflow built on a model that is later deprecated will break in the client’s hands unless someone owns the upgrade.

The clean answer is to decide all three in the proposal. Credentials live in the client’s accounts from day one. Prompts and orchestration logic specific to the client’s process are the client’s; the patterns and sub-workflows you reuse across clients are yours, and the contract says so. And the retainer, which you should be selling anyway, is where model deprecations get handled.

Licensing what you own

AI labs training coding models need real production code and the git history behind it: how features were built, how bugs were fixed, how a codebase changed over years. That cannot be generated, so they pay for it. The program this site partners with works as follows. Every figure below was checked against the partner’s published terms on 15 September 2026 and is indicative, which means it depends on the sale and on buyer demand.

Non-exclusive. You grant a license and keep full ownership, including internal use and ongoing client work. The same repository can be licensed more than once, and you are paid each time. How often depends on demand.
Rates. Around $100 per million tokens of source and $40 per million tokens of git history. History makes up about 95 percent of the tokens in a typical repository, so it is where most of the money is. The rates can change on 30 days notice and never retroactively.
What qualifies. Private repositories you own or hold the rights to license. Client-owned work, anything that was ever public, forks, and anything carrying confidential data or third-party rights are excluded. Generated files, vendored code, binaries and data dumps are not counted.
Process. You request access, sign once, grant read-only access to GitHub, GitLab or Bitbucket, and pick the repositories yourself. Secrets and personal data are stripped from the copy pulled for review. The repository is graded and taken to buyers in batches.
Timing. An estimate on connecting Git. Grading from hours to four weeks. Licensing normally two to sixteen weeks, and never guaranteed. Payment within 15 days of the buyer paying.
The ballpark. The partner’s own illustration is roughly $1,000 to $1,500 take-home per repository, with no fee to join and nothing taken from your share.
The warranty. You warrant that you own or may license everything you submit, and that warranty is uncapped. A wrong one can mean returning payments and covering claims. This is the paragraph to read twice, and it is why the sort above comes first.

If the second pile is real, check what the repositories might be worth. It takes a few minutes and commits you to nothing.

What not to do

Do not submit anything with a client’s name in it, whatever the contract says, because the confidentiality clause usually outlives the IP clause. Do not make a repository private now to qualify it; anything that was ever public is excluded. Do not license a mixed repository. And do not skip the contract read because the code is old. Age does not change who owns it.

And the agency itself

An agency sorting its old code is usually an agency thinking about what comes next. If what comes next is an automation practice, the buyers on this site are looking for it. Get listed: it is free, and the review will tell you what a buyer sees.