What Happens to Your Code If Your Development Agency Goes Under?

Most founders assume they own the code their agency built. Most are wrong.

Not wrong in a theoretical sense. Wrong in the way that surfaces during a due diligence call with an investor, or when your agency goes dark and you try to push a deploy without them, or when a lawyer reads your development contract and asks whether you have the actual assignment documents. That kind of wrong. The kind where you are in trouble before you know there is a problem.

This is the question almost nobody in the agency world will answer directly, because a direct answer forces a conversation agencies would rather skip. Here is what actually happens.

The assumption most founders make

You hired an agency. You paid them. They built you a product. The code is in a GitHub repo. Therefore, you own it.

Two of those four things are definitely true. The second two depend entirely on what your contract says and whether it says it correctly.

Under US copyright law, software is a "work of authorship." Authorship vests with the creator at the moment of creation, meaning the developer who wrote the code, or the agency employing that developer, not the client who paid for it. The fact that you commissioned the work and paid for it does not transfer ownership by default. There is a carve-out in copyright law called "work made for hire" that can shift that default, but it only applies to independent contractors in a specific set of enumerated categories. Custom software is not on that list.

What this means in practice: a contract that says the deliverables "shall be considered works made for hire" may not actually transfer ownership to you, because courts may find software falls outside the qualifying categories. Attorneys at Willcox Savage flagged exactly this failure in a 2025 analysis of common development contract templates -- many of them contain ownership clauses that do not accomplish what they appear to say. The correct language is an explicit written assignment: something along the lines of "Developer hereby assigns to Client all right, title, and interest, including all intellectual property rights, in and to the work product." The assignment has to be present, signed, and written in language that actually transfers ownership. Most boilerplate contracts do not have it.

What happens when the agency shuts down

Now layer in a shutdown. Agencies fold for ordinary reasons: the principal burns out, a key client leaves, the economics stop working. When that happens, a few things get complicated fast.

If your contract contains an actual IP assignment, and the work was properly assigned before the shutdown, you are in reasonable shape. The rights transferred to you when the assignment was signed, not when the agency closed. You own what you own.

If your contract does not contain a proper assignment, or if deliverables were never formally transferred, those rights become part of the agency's estate. The bankruptcy trustee can treat them as assets. In a Chapter 7 liquidation, a trustee's job is to sell assets to pay creditors. That could, in theory, include IP they hold in your product. In practice this almost never gets exercised, because custom software has near-zero resale value to anyone other than you. The more common damage shows up later: unclear ownership surfaces during fundraising, exits, or any deal where someone actually reads the contracts.

There is also the access question, which is separate from the ownership question and often more immediately painful. Even if you technically own the code, if it only exists on the agency's servers, or their AWS account, or a private GitHub org you are not an admin of, you need to get it out first. Agencies that go under quickly do not always do orderly handoffs. Servers get shut off. Accounts go dormant. The people who knew the passwords are gone. Recovering access is usually possible but often slow and sometimes expensive.

The access problem extends beyond the codebase itself. Any API credentials, cloud accounts, or third-party service integrations the agency set up: are they in your name, or theirs? That is not an IP issue. It is an access issue. But it can be just as blocking if the answer is theirs, especially if the agency has gone dark and cannot or will not hand anything over.

The parts of your stack that are not your code

There is a third problem that ownership language does not solve.

Most software products are not purely original code. They sit on top of third-party libraries, open-source packages, and licensed frameworks. The ownership clause in your contract covers what the agency wrote. It does not affect your obligations under the licenses of everything it was built on top of. Some of those licenses are permissive and you will never think about them again. Some are not.

If the agency used any proprietary tools, templates, or internal frameworks in your build and did not license those to you explicitly, you may be running on software you have no right to. This is less common with good agencies and more common with bad ones. It is worth knowing which category yours falls into before you find out the hard way.

What a clean arrangement actually looks like

None of this has to be complicated. The clean version is not hard to set up; it just requires agencies to commit to it upfront, which most are not inclined to do because it removes any hold they have over you.

The clean version looks like this.

The code goes in your GitHub org from day one. The agency is a collaborator on your repo, not the owner of it. The moment you stop paying them, you do not need their cooperation to keep the codebase.

The cloud infrastructure is in an account registered to your company. The agency may manage GCP, AWS, or Azure on your behalf, but the account belongs to you. If they disappear tomorrow, your application keeps running.

The contract contains an explicit, written IP assignment: a signed transfer of all right, title, and interest in the deliverables, in language a lawyer would recognize as sufficient. "Work made for hire" with no assignment on top of it does not clear that bar.

If the agency uses internal frameworks or templates in your build, those need to be explicitly licensed to you in writing. Failing that, you may be running on software you have no right to, and you will not know until someone asks.

This is not a negotiating concession you should have to fight for. If an agency pushes back on any of it, if they want to hold the repo, manage the cloud account under their credentials, or keep the IP assignment vague, that is the answer you needed before you started.

How we do it

At SociiLabs, you own everything from Day 1. Your repo is in your GitHub org before we write the first line of code. Your cloud infrastructure is in your account. The IP assignment is in the contract, with language that transfers ownership cleanly. We do not hold anything over your head.

We see the relationship as a technical partnership, not a gatekeeping arrangement. The moment you want to bring development in-house, hand it to another team, or raise a round where investors read the contracts carefully, you should be completely free to do that. That is only possible if the ownership was yours from the start.

If you have an existing build and you are not sure who actually owns what, that is worth sorting out before it matters. We can walk through it with you in a scoping call.

Book a 30-minute call: cal.com/sociilabs/30min