How to Get Your Source Code Back From a Developer

To get your source code back from a developer, ask in writing for a transfer of the repository with its full history into an account your company owns, plus everything needed to rebuild and run it: migrations, configuration, the list of services and secrets, and deploy steps. Then prove it is complete by building it from a clean checkout. Your contract decides how much you can insist on.

This guide is for the planned exit: a contract ending, a switch of agency, a freelancer moving on, or a developer who is slow to hand over but still answers. If your developer has stopped responding altogether, start with the 48-hour recovery plan instead, which covers locking down accounts when nobody is cooperating. For taking over the code once you have it, see the Code Rescue Playbook. Nothing here is legal advice; the contract sections are general information, so confirm with your adviser.

What counts as "the source code" in a handover?

Much more than a zip of the current files. A handover is complete when someone who has never seen the project can rebuild it, deploy it and run it against your data. This checklist is what to ask for.

Item	Why it matters	How to check you have it
The repository with full history, every branch and tag	History explains why code is the way it is; branches may hold unreleased work	Clone with --mirror and compare branch counts with the developer's list
Database schema and migrations	Without them the database cannot be rebuilt or safely changed	Replay the migrations on an empty database
Configuration and infrastructure files	Build settings, server config, scheduled jobs, infrastructure-as-code	A clean build and deploy using only what is in the repository
A list of environment variables and secrets	The app will not start without them	Names and purpose for every variable; values set by you in your own accounts
Third-party services the app uses	Payments, email, maps, storage, error tracking	Every service is on an account you own, or on the list to move
Build, deploy and run instructions	Knowledge that often lives only in the developer's head	A new developer follows them without asking questions
Design files and documents	Specifications, designs, API docs you paid for	Moved to your own workspace, not shared links from theirs

Ask for items, not effort. "Hand over the code" invites a zip file; "transfer the repository to our organisation, with all branches, and send the list of environment variables" gets you something you can check.

Who should own the accounts, and how do they move?

Your company should be the owner of every account; the developer should be a member you can remove. Owner and member are different permissions on almost every platform, and only an owner can transfer or delete.

The two transfers most founders need are the repository and the hosting project, and both platforms document how they work:

• GitHub repositories. The person transferring needs administrator access to the repository. Issues, pull requests, wiki, stars and watchers move with it, and links to the old location redirect to the new one. A transfer to a personal account expires if it is not accepted within one day, and the target account must not already have a repository with the same name (GitHub: transferring a repository). Create your organisation first, so the developer can transfer straight into it.
• Vercel projects. The developer must be an owner of the team the project is in and a member of the team it goes to. Deployments, environment variables, domains and cron jobs move; integrations, log data and monitoring do not, and integrations must be added again afterwards (Vercel: transferring a project). Other hosts have similar processes; read theirs before the call.

The full list of accounts a product depends on, from the domain registrar down, is in the recovery plan's access inventory. Use it as the checklist for the handover call, and do not remove the developer's access until your own admin access works on each one.

How do you ask a developer or agency for the code?

In one written message, with a list and a date. Most handovers stall because nobody said exactly what "done" means.

1. State the reason plainly. "We are moving development in-house" or "the contract ends on 30 November" is enough. No blame.
2. List the items from the table above, and the accounts to be transferred into your company's name.
3. Say how: a transfer into your organisation, not a download. Offer to create the destination accounts first.
4. Book a handover call of an hour or two, where they walk a new developer through build, deploy and the parts that break.
5. Ask about data they hold. Request written confirmation that copies of production data on their machines are deleted once the handover is done.
6. Give a date, and quote the handover clause if your contract has one.

If the relationship is tense, keep the message about the product rather than the dispute. Paying for handover time is often faster and cheaper than arguing about whether it is included.

How do you check the code you received is complete?

Build it from scratch on a machine the developer never touched, and confirm that production is running a commit you actually have. Two quick commands cover the first part of that:

# 1. Keep a full, offline copy of every branch and tag.
git clone --mirror https://github.com/your-org/your-app.git
cd your-app.git
git bundle create ../your-app-handover.bundle --all
git bundle verify ../your-app-handover.bundle

# 2. Confirm the commit running in production is in your copy.
#    Prints "commit" if you have it; errors if you do not.
git cat-file -t <commit-sha-shown-in-your-hosting-dashboard>

Git's documentation describes a bundle made with --all as a full backup of the repository's refs and commits, while noting it does not include local state such as configuration or hooks (Git: git-bundle). Store the bundle somewhere the developer has no access to.

Then run the checks a new team would: a clean install and build with the host's exact commands, migrations replayed on an empty database, a secret scan over the full history, and the test suite. The Code Rescue Playbook explains what each result means and what a full diagnostic adds.

Do you own the source code you paid for?

Not automatically. Whether you own it depends on your contract and the law where it was made. This is general information, not legal advice; confirm with your adviser.

In the United States, for example, the Copyright Office explains that a work is "made for hire" either when an employee creates it in the course of their job, or when it is specially commissioned in one of nine listed categories under a signed written agreement (U.S. Copyright Office, Circular 30). Software written by an independent contractor is not one of those nine categories, so without a written assignment, the contractor may keep the copyright even though you paid for the work. Other countries have their own rules, which is exactly why the clause in your contract matters more than the invoice.

If your contract is silent or vague, raise it before the relationship ends, while goodwill still exists. A short signed assignment of the code delivered so far is a small request for a developer who is leaving on good terms.

Which contract clauses protect your source code?

Six clauses do most of the work. Use this as a list of questions for your adviser, not as contract wording.

Clause	What it should cover	Why it matters at handover
IP assignment	A present assignment of the code and related work to your company	Removes the doubt described above; a promise to assign later is generally treated differently
Definition of deliverables	Source code with history, migrations, configuration, documentation	Turns "hand over the code" into a list you can check
Where the code lives	Your repository, in your organisation, from the first commit	Nothing to hand over later, because you already hold it
Account ownership	Hosting, domain, database and services registered to your company	The developer is always a removable member
Handover on termination	A set period of cooperation, a handover session, deletion of your data	Makes the exit a scheduled task, not a negotiation
Third-party and open-source components	Disclosure of libraries and licences used	You inherit their licence terms along with the code

RAITHub's own terms assign IP to the client through a present-assignment clause, and an NDA is standard before any code is shared; the security page describes how access is handled.

Is source code escrow worth it?

For custom software you commission, usually not; keeping the repository in your own organisation does the same job for free. Escrow earns its fee when you license software you do not own and could not replace quickly.

Source code escrow is "the deposit of the source code of software with a third-party escrow agent", released to you on agreed conditions such as the supplier's bankruptcy, cancellation of the project, or refusal to meet maintenance obligations. Specialist agents can also verify a deposit, from checking that it is readable up to building the software and comparing it with the version you run (Source code escrow, overview).

Situation	Better protection	Why
A freelancer or agency builds software for you	Repository in your organisation from day one, plus IP assignment	You hold the code continuously; nothing needs releasing
You license a supplier's product that your business depends on	Escrow with verification	You cannot hold their repository, but you can hold a tested deposit
You depend on a hosted service run by a small supplier	Escrow that includes deployment documentation, plus regular exports of your data	Code alone does not run a service; you need the data and the steps

An escrow deposit that has never been built is a hope, the same as a backup that has never been restored. If you pay for escrow, pay for verification too.

Why RAITHub for this, and when you don't need us

RAITHub's Code Rescue engagement starts where a handover ends: access secured, code received, and nobody on your side who knows it yet. The first step is the access inventory, then a 2-week diagnostic covering the codebase, the infrastructure and a risk register, so you know what you received before you decide what to change. Quotes are fixed and written after a free 15-minute technical audit, and IP in all work is assigned to you.

You don't need RAITHub if:

• The handover went cleanly and a new developer you trust can build and deploy from what you received.
• Ownership of the code is in dispute. See a lawyer first; RAITHub gives no legal advice.
• You only need one bug fixed in the code you got back. Start from the fix one issue page instead.
• You need a certified vendor or delivery in a language other than English. RAITHub is not SOC 2 or ISO 27001 certified and works in English.

If you have the code and need someone to take it over, pick Code Rescue on the contact form and book the free 15-minute audit. Bring the handover checklist above, filled in as far as you can.

Platform documentation checked on 29 September 2026.

Frequently asked questions

How do I get my source code from a developer?

Ask in writing for a transfer of the repository, with full history, into an organisation your company owns, plus migrations, configuration, the list of environment variables and services, and deploy instructions. Then build it from a clean checkout to prove it is complete.

Can a developer legally keep my source code?

It depends on your contract and jurisdiction. In the US, software from an independent contractor is generally not a work made for hire, so without a written assignment the contractor may keep the copyright. This is general information; confirm with your adviser.

Is a zip file of the code enough?

No. A zip loses the history and branches, and usually leaves out migrations, configuration and deploy steps. Ask for a repository transfer into your own organisation and check it with a mirror clone and a clean build.

What should a developer handover include?

The repository with every branch and tag, database migrations, configuration and infrastructure files, a list of environment variables and services, build and deploy instructions, design documents, and a handover call with the next developer.

Do I need source code escrow for a custom app?

Usually not. If the repository sits in your organisation from the first commit and the contract assigns IP to you, you already hold the code. Escrow suits software you license from a supplier and do not own.

Should I remove the developer's access before the handover is finished?

No. First confirm your own admin access works on every account and that you have a verified copy of the code. Then remove their access and rotate the secrets they knew.