Who Owns Your Software? Access, Accounts and Code Ownership After a Developer Leaves

A founder calls her agency three weeks after the freelance developer who built her platform stops answering emails. The code runs fine. The problem is that nobody at the company can log into the GitHub repository, the Stripe account is registered to his personal email address, and the domain renewal notice just bounced back to an inbox that no longer exists. She asks the obvious question: who owns my software code? For a surprising number of small and mid-size companies, the honest answer is that it depends on who kept the passwords.

This is not a rare edge case. It is what happens when a company treats a developer relationship as a technical arrangement instead of a business one, and ownership gets settled by default instead of by contract.

Who owns my software code? Ownership and access are two different problems

Most service agreements include a line assigning intellectual property in the work product to the client once it is paid for. That clause matters, and it is worth having. But it answers a legal question, not a practical one. Owning the copyright to code you cannot reach does not help you ship a fix, rotate a leaked key, or renew a certificate before it expires.

Access is a separate layer: who holds the login, who controls the organization account, whose name is on the domain registration. A contract can make a company the legal owner of its code on day one and still leave every operational account sitting under one person's personal email. That gap is where most "who owns this" disputes actually live, and it rarely shows up until someone needs access and finds out they do not have it.

Employees, freelancers and the ownership default

The legal default depends on who wrote the code and under what arrangement, and it catches most non-technical founders off guard. In many jurisdictions, code written by a salaried employee within the scope of their job belongs to the employer automatically, simply because of the employment relationship. Freelance and contract work usually does not get the same default. Without a written clause assigning the copyright, the freelancer who wrote the code can remain its legal owner even after the client has paid in full, with the client holding only an implied license to use it.

This is exactly why code ownership freelancer disputes come up so often during contract reviews. The fix itself is not complicated: a single sentence assigning all rights in the work product to the client upon payment, written into the contract before work starts. What is complicated is noticing the gap exists at all, since most verbal agreements and short statements of work never mention it, and the omission only matters once the relationship ends.

The specific rules vary by country and by whether the arrangement qualifies as commissioned work under local law, so a contract reviewed by a lawyer familiar with your jurisdiction is worth the modest cost compared to the dispute it can prevent later.

Where ownership quietly slips away

A handful of accounts cause almost every dispute of this kind:

• The source code repository, when it was created under the developer's personal GitHub or GitLab account rather than the company's organization.
• Domain registration, often set up quickly during a project kickoff and never transferred afterward.
• Cloud hosting and infrastructure accounts such as AWS, Vercel, DigitalOcean or Supabase, which usually have billing and admin rights tied to a single email address.
• Payment processing accounts such as Stripe or PayPal, where ownership transfer requires identity verification that can take weeks to clear.
• API keys and paid subscriptions for services the application depends on, from email delivery to analytics to error tracking.
• A password manager vault or shared credentials document that only the departed developer could unlock.

None of this requires bad intent to become a problem. Most developers are not trying to hold a client hostage. They set up the fastest account available during a sprint, meant to transfer it later, and later never came.

What most contracts miss

A standard clause stating that deliverables become client property upon final payment covers the code itself. It rarely covers the accounts the code runs on, and it almost never sets a deadline or a process for the handover. Without that detail, transferring access becomes a favor the departing developer can delay, forget, or, in a dispute over scope or payment, use as leverage.

The freelancers and agencies with the cleanest track record on this tend to do one thing differently: they treat account ownership as part of the deliverable rather than an afterthought to it, and they put that in writing before the project starts.

Clauses worth adding before you sign

A few additions to a standard development contract remove most of the repository access risk that shows up after a developer left:

• Require that the repository, hosting account and domain be created under company-controlled accounts from the start of the engagement, not transferred at the end of it.
• If a developer's personal account has to be used temporarily, require that the company be added as an owner or admin within the first week, not at offboarding.
• Define a written offboarding checklist, listing every account, API key and credential in scope, as a condition of final payment rather than a courtesy afterward.
• Set a specific deadline for completing the handover once the engagement ends. Five to ten business days is common.

None of this requires distrust of the developer. It treats access the way a company already treats office keys or building badges: issued on purpose, tracked, and returned on a schedule rather than assumed.

If the developer has already left

When the handover did not happen and the relationship has already ended, recovery is usually possible but takes longer than anyone expects.

Start with what you can prove. Business registration documents, the signed contract and payment records establish that the company, not the individual, commissioned and paid for the work. GitHub, domain registrars and most cloud providers have a documented process for recovering an account or organization when the requester can show legitimate business ownership, though it can take several days to resolve and longer if the original account holder is unresponsive.

Check the repository's commit history and configuration files first. They often reveal account names, linked email addresses and service providers that nobody wrote down anywhere else. A short technical audit at this stage, before a new team starts changing anything, also surfaces other gaps such as hardcoded credentials, undocumented dependencies or infrastructure that only made sense to the person who built it. Wolf-Tech's legacy code optimization work often starts exactly here, mapping what a codebase actually depends on before anyone touches it.

If a provider will not cooperate and the developer is simply unreachable, a short letter from a lawyer referencing the signed IP assignment clause is usually enough to resolve it. Outright refusal to hand over access that a contract already assigns is rare, mostly because few developers want that dispute on record.

Building the next project so this cannot happen again

If you are starting a new build rather than recovering an old one, the fix is simpler. Set up company-owned accounts for the repository, hosting, domain and billing before any code gets written, and add the developer or agency as a collaborator on those accounts rather than the other way around. Wolf-Tech's custom software development engagements follow this structure by default, so access and ownership are never a separate conversation from the build itself.

If you have inherited a codebase and are not sure what you actually control, we are happy to take a look. Email hello@wolf-tech.io or find out more about how we work at wolf-tech.io.