Who Owns the Code My Developer Writes?

My developer built our app in their own GitHub and their own Firebase account. Now we're parting ways and they say they'll send the code. Is that enough, and who actually owns it?

You should, but the code alone isn't enough. The accounts it runs on matter more: the repository, the cloud and database accounts, every key and the domain. All of them belong in your name.

A copy of the code is a snapshot. The app itself lives in the developer's Firebase project, with its data, its users and its bill.

Until that project is yours, you own a copy of an app someone else runs.

The Contract Decides Who Owns the Code

Whoever the contract names owns the code. Make it you, from the first commit, in a repository under your account.

Holding a repository and owning what's in it are two separate questions. Today your developer holds the repository. Only a contract answers who owns its contents.

A fair contract says two things. The work belongs to the company that paid for it. The developer keeps only what they brought along: the general patterns and know-how they use on every project.

The rule covers more than code. A prototype and its live link are the client's from day one. So is an internal tool with its data.

The same goes for a written plan. The company that paid for it should be free to edit it, resell it or hand it to another team.

With an agency in the middle, the owner is the agency or its client, whichever their contract names.

That ownership is what makes stopping cheap. A founder who owns it all can hand it to anyone, because it already sits where it belongs. What if my developer doesn't work out? covers that exit.

A contract settles the rights, though. It doesn't move a single account.

The Accounts Matter More Than the Code

Code can be copied. A database in the developer's account can't be taken back without them.

That's the gap in the developer's offer. The code they send arrives as a zip or a fresh repository. The Firebase project keeps what the code needs to run: the database, the users who sign in, the hosting and the bill.

The same holds beyond apps:

• For a bot: the repository, the hosting, the bot's accounts and the model keys.
• For automations: the platform account with its workflows.
• For a website: the hosting, the builder account, the domain, the posts and the email list.

Each one should be opened in the client's name and billed to the client's card. The developer gets a seat with enough access to do the work, and the client can remove that seat alone.

I've been the developer in this question. Years before I wrote the rule down, one project's repository sat in a GitHub organization named after my studio. Moving it to the client took one evening, because I was there to do it.

The second time was recent: months into a retainer, the work still ran on my accounts. I moved it to a GitHub organization and two fresh Firebase projects in the client's name. I apologized for not doing it sooner, and the day-one promise on my homepage came after it.

That's the whole risk: an account in the developer's name moves only while the developer cooperates. So the accounts are what to ask for.

Four Things to Get Back

The ask comes down to four things: the repository, the cloud and database accounts, every API key and the domain. Anything still in the developer's name moves into yours before any new work starts.

The handover checklist has one line for each:

1. The repository, transferred to your account with its full history. A zip loses the commits, and the commits are where the decisions are.
2. The cloud and database accounts, with you as the owner and billing on your card. Here, that's the Firebase project, with the old developer's access removed.
3. Every API key, as a list of the services the app calls, each account in your name. Rotate any key the old developer could see.
4. The domain, with the registrar account in your name. A free DNS lookup shows where it points today, which tells you which host to check next.

An agency taking over a client's app needs the same four.

The four carry the product, and the reasons behind it need a home too. That home is the repository. Pull requests explain why a change was made, and decision records live next to the code, as Documentation describes.

With those in hand, the next developer reads instead of reverse engineering. If no contract was ever signed, one question stays open: who owns the code itself.

The Default Without a Signed Assignment

Without a written agreement, code ownership depends on the country. In many, the US and the UK among them, a freelancer who signed no assignment keeps the copyright. The client may only have the right to use the code.

The US Copyright Office's guide to works made for hire, revised in August 2024, shows why. A commissioned work counts as made for hire, and so is the client's from the start, only on two conditions. It has to fall into one of nine categories, and both sides have to sign an agreement saying so. Software isn't named among the nine.

For a founder parting ways now, that's a question for a lawyer before the last invoice is paid.

How I Set Up Ownership

With me, the setup comes first. The client owns what I build from day one, and none of it sits on my accounts. When I build under an agency's brand, I'm a contributor, never the owner.

Access is quick to give when the accounts are already the client's. When I joined one product, the paperwork and access were done by the end of the next day. Leaving is the same step in reverse.

When I take over code from another developer, access comes first. Anything in the last developer's name moves to the client before I change a line. An audit lists it as its first row.

If your developer has gone quiet, it's where a one-week rescue starts. The week runs a deep dive, moves the access into your name, ships the urgent fixes and ends in a plan.

After a cancellation, if asked, I finish things up or write handover notes until the week ends. That's part of Exit Freedom.

When the next step is a team, I either stay as the senior engineer or hand over access, docs and history. The price is on the homepage.

What the Founder Should Do Now

Move all four into your name before the last invoice. A new developer or team then gets access, and nothing else changes.

The checklist is the agenda for the last conversation with the developer, while they still answer.

Before they leave, ask for what lives only in their head: open tasks, known bugs, the fix they meant to ship. After they leave, rotate the keys they saw and remove their seats.

Set up from day one, none of this would be needed: you would remove one contributor from accounts you already own. If the next question is a hire, Do I need a CTO yet? answers it.

The contract decides who owns the code. Whoever holds the accounts when the developer is gone owns the product, and that should be you.