Skip to main content
Custom Software · Ownership

Who Owns the Source Code of Custom Software?

Paying a developer does not automatically make you the owner. What US copyright law says, where the code and accounts should live, and what to put in the contract.

If you pay a developer to build custom software, you might assume you own the source code. Under US law, that assumption is often wrong unless the contract says otherwise, and the contract is only half the story. Legal ownership is one part of control; the other is who holds the repository, the cloud account and the keys.

This matters most on the day you want to leave. A founder retires, a developer disappears, a firm raises its rates, or you simply want a second opinion. Whoever holds the code and the accounts decides how painful that day is.

Below is a plain-language guide to the basics, the practical ownership checklist, and what to put in the agreement. It is general information and not legal advice: have a Washington-licensed attorney review any real contract. If you are still deciding whether to build at all, start with our guide to custom software for small business.

Want ownership terms settled up front? Request an estimate and we will reply with scope and a price range for a sensible first phase.

The default rule: the creator owns it

US copyright law starts from a simple rule. Under 17 U.S.C. § 201, copyright vests initially in the author of the work. Paying for something does not by itself make you the author. Source code is a creative work, so a developer who writes it starts out owning the copyright, even if you commissioned it, unless an exception applies.

Two exceptions matter: work made for hire, and a written transfer.

Work made for hire, and why it often does not fit

The US Copyright Office explains this in Circular 30, Works Made for Hire. A work is made for hire in two situations: when an employee creates it as part of their regular duties, or when a certain type of work is created under an express written agreement with the party commissioning it.

  • Employees. Your own staff, acting within the scope of their jobs, create works you own. Whether someone is an employee or a contractor is decided under general agency law, and the Circular lists factors such as who supplied the tools and workspace, how long the relationship lasted, how the person was paid, and whether they run their own business. A development firm or freelancer is normally an independent business, not your employee.
  • Commissioned works. The Circular lists nine categories that can qualify, including contributions to collective works, translations, compilations and instructional texts, and the parties must sign a written agreement saying the work is made for hire. Software is not among the nine categories the Circular names.

The practical takeaway: do not rely on a “work for hire” sentence alone for commissioned software. Whether a given piece of code fits a category is a legal question for your attorney, and a contract that depends on it can leave you with less than you thought. That is why the second exception does the heavy lifting.

The reliable path: a signed written assignment

Copyright can be transferred. Under 17 U.S.C. § 204(a), a transfer of ownership is not valid unless an instrument of conveyance, or a note or memorandum of the transfer, is in writing and signed by the owner of the rights conveyed (or the owner's duly authorized agent).

So an IP assignment clause, signed by the developer, is the tool that actually moves ownership to you. A handshake or full payment does not transfer copyright, and an informal email saying “it's yours” is a shaky foundation for something this important. Two details to settle in the clause: when the transfer happens (on creation, or only after final payment) and what transfers (your custom code, but usually not the developer's pre-existing tools and libraries, which are typically licensed to you instead).

Ownership in practice: repository and cloud accounts

You can own the copyright and still be stuck if the code lives somewhere you cannot reach. Check four things.

  1. The repository. The code should live in a GitHub (or equivalent) organization you own, with you as an owner from day one. If it starts elsewhere, GitHub documents how a repository transfer works: issues, pull requests, wikis and commit history move with it, and the person transferring needs administrator access. Transfers are possible, but they are easier to do on day one than during a dispute.
  2. The cloud account. Hosting should sit in an account opened in your business name, billed to you. On AWS, for example, the account's root user is tied to the email address and password used to create it and has complete access to every service and resource in the account. Whoever controls that email controls the account. The developer should work through limited access that you grant and can revoke.
  3. Domains, DNS and third-party services. Payment processors, email services, analytics and API keys should be registered to you too.
  4. Documentation and secrets. A handover is only real if someone else can build, deploy and run the system. Ask for setup instructions, an architecture note and a list of every service and credential involved.

Source code escrow: when it helps

Sometimes you will not own the code. A vendor may license you a product and keep the source. In that case, escrow is the usual safety net. A source code escrow arrangement involves the developer (depositor), the customer (beneficiary) and an escrow company that holds the code and related materials. The code is released to you if defined events occur. Typical release events described by that guide include failing to support the product and not fixing it after written notice, insolvency or bankruptcy proceedings, and the developer ceasing operations.

Two cautions. Escrow only protects you if deposits are kept current, so ask for a verification process. And escrow is a fallback. If you are commissioning software built for you, owning the code outright from the start is simpler and cheaper than renting a safety net.

What to put in the contract

  • An IP assignment of the custom work to you, signed by the developer, with clear timing.
  • A work-for-hire statement as a belt-and-suspenders addition, not a substitute for the assignment.
  • A license for pre-existing and third-party code the developer reuses, perpetual enough that your system keeps working.
  • Repository and cloud ownership in your accounts from the first day, with named administrators on your side.
  • Handover obligations: documentation, credentials, and reasonable help transitioning if you leave.
  • Subcontractor language: anyone the developer brings in must also assign their work.
  • Portfolio and confidentiality terms so you know what the developer may show or reuse.

The honest verdict

If you are buying a product (a CRM, a no-code tool, a hosted platform), you will not own the code and should not expect to. Judge it on data export, uptime and price, and consider escrow only for vendors you truly depend on and who are small.

If you are commissioning custom software, insist on the signed assignment, the repository in your organization and the cloud account in your name. Those three cost little or nothing at the start and are very expensive to fix later.

That is how we work: code and cloud accounts are yours from the start, as described on our custom software for small business page. When comparing firms, our guide to choosing custom software development companies puts ownership terms on the checklist. This article is general information, not legal advice.

Start your project — takes 90 seconds

Request an Estimate

Tell us what you want built. We’ll reply with scope and a price range for a first phase, with code, repository and cloud accounts in your name.

Fields marked * are required.

What do you need built? *

By submitting, you agree to be contacted at the email or phone above. We never share your information.

Frequently Asked Questions

Do I own the code if I paid a developer to write it?

Not automatically. Under US copyright law the author of a work owns it initially, and a contractor who writes your code is normally the author. Ownership reaches you through a signed written transfer or, in limited cases, a work-made-for-hire arrangement. Payment alone does not do it. Make sure your contract includes a signed intellectual property assignment, and have a Washington attorney review it. This is general information, not legal advice.

Is custom software a work made for hire?

Code written by your own employees within the scope of their jobs is. Code from an outside developer is different: commissioned works qualify only if they fit one of nine categories listed in the copyright statute and both parties sign a written agreement. Software is not named among those categories. So a contract for commissioned software should rely on a signed assignment, with any work-for-hire wording as a backup. Ask your attorney how it applies to your project.

What is source code escrow and do I need it?

Escrow means a neutral company holds a copy of the source code and releases it to you if specific events happen, such as the vendor going out of business or failing to support the product. It is useful when you license software you do not own and depend on a small vendor. If you are commissioning custom software and own the code, the repository and the cloud account from day one, you usually do not need it.

What should I get when a custom software project ends?

You should receive the signed assignment, administrator access to the repository in your organization, control of the cloud account and domains, documentation that lets another developer build and deploy the system, and a list of every third-party service and credential involved. If any of these stays with the developer, you have a dependency instead of an asset. Ask for these in the contract before work starts, since they are far easier to secure then than during a dispute.

Ready to Start?

See if custom is right for your business.

Take the free WorkflowUnity Business Automation Audit — an AI-led conversation, 3–5 minutes, no account required. You'll get a clear readiness score across Automation, Efficiency, Cost Clarity, and Scale Readiness.

Take the Audit → Get a Free Estimate →