Who Owns Your Custom Software? The Paperwork That Decides

The invoice is not the transfer

Most owners assume that paying for software makes them the owner of it. It is a reasonable assumption. It is also not how United States copyright law works, and the space between the assumption and the law is where a lot of small businesses sit for years without ever noticing.

Usually nothing goes wrong. The developer stays friendly, the site keeps running, and the question never gets tested. It gets tested at the three moments that matter most: when you want to move to a different developer, when someone wants to buy your business, and when the person who built the thing stops answering email.

This post is about who holds what, on paper and in practice. It is narrower than our piece on buy vs build, which is about whether to commission software at all, and it sits beside our post on AI generated code security, which asks whether the code is safe rather than whose it is. Here the only question is ownership.

Work made for hire does not cover software

The phrase everyone reaches for is work made for hire. It comes from 17 U.S.C. 101, and it has two branches. The first covers work prepared by an employee within the scope of employment. If you have a salaried developer on payroll, that branch does most of the work for you.

The second branch is the one that applies when you hire a contractor or an agency, and it is far narrower than its reputation. A specially ordered or commissioned work can be a work made for hire only if it falls into one of nine listed categories, and only if both parties expressly agree in a signed writing. The categories are a contribution to a collective work, a part of a motion picture or other audiovisual work, a translation, a supplementary work, a compilation, an instructional text, a test, answer material for a test, and an atlas.

Read the list again and look for software. It is not there, and it never has been. A contract that simply calls your web application a work made for hire is, on that clause alone, describing something the statute does not recognize for software.

Well drafted agreements handle this with a second clause: a present assignment of copyright to you, in writing. 17 U.S.C. 204 is blunt about why that writing has to exist. A transfer of copyright ownership is not valid unless it is in writing and signed by the owner of the rights being conveyed. No writing, no transfer. An invoice marked paid is not an instrument of conveyance.

So the practical test for a development agreement is not whether it contains the phrase work made for hire. It is whether it also contains an assignment, in the present tense, signed by the party that wrote the code.

The newer gap: code a machine wrote

Now add the part that did not exist five years ago.

United States copyright protects works of human authorship. That has been the Copyright Office position throughout, and it is now settled at the appellate level. In Thaler v. Perlmutter, the D.C. Circuit held on March 18, 2025 that the Copyright Act requires a human author. The Supreme Court denied review on March 2, 2026, which closes the question for the foreseeable future.

The Office worked through what that means for ordinary AI assisted work in Part 2 of its Copyright and Artificial Intelligence report, published January 29, 2025. Three of its conclusions matter to a business owner. Prompting alone does not give the user enough control over the expressive elements of an output to make them its author. Human authored material that remains perceptible in the result stays protected. And a person's own selection, arrangement, and modification of generated material can be protected as their contribution.

The Office's registration guidance, published at 88 Fed. Reg. 16,190 on March 16, 2023, separately requires an applicant to disclose AI generated material and disclaim it from what is being claimed.

Now apply all of that to a real project. A build shipped this year contains hand written code, generated code a developer reshaped substantially, and generated code that landed close to how it came out. The first two carry human authorship. The third may carry none, which means there may be nothing there to assign. A perfect assignment clause transfers whatever exists, and it cannot manufacture a copyright the law says never arose.

What protects you when copyright is thin

Three things, and none of them turn on the authorship question.

The first is your contract. Copyright is a default rule. A contract is a promise between two named parties, and a developer who agrees in writing not to reuse your system for anyone else is bound by that promise whether or not a court would find a copyright attached. That is the clause worth caring about, and it is the one most template agreements skip.

The second is trade secret law, and Utah's version is unusually direct on this point. Under the Uniform Trade Secrets Act at Utah Code 13-24-2, a trade secret means information, and the statute's own list of examples includes a program. There is no human authorship requirement anywhere in it. What the definition does require is in its second half: the information has to derive independent economic value from not being generally known, and it has to be the subject of efforts that are reasonable under the circumstances to maintain its secrecy.

That last clause is a to do list wearing the costume of a definition. Reasonable secrecy efforts mean the repository is private, access is limited to people who currently need it, departed contractors are actually removed rather than theoretically removed, and credentials are not sitting in a shared inbox. A business that handed its source code to five vendors over six years and revoked nothing has spent a protection it was entitled to.

The third is possession, which is the least legal and the most decisive.

Ownership you can actually exercise

Ownership on paper is worth exactly what your ability to act on it is worth, and the checkable version has nothing to do with statutes.

Ask who holds the accounts. Not who has access, who holds them. The code repository, the domain registrar, the DNS, the hosting account, the database, the transactional email service, the analytics property. If the answer for any of those is a vendor account with you added as a sub user, you do not hold that piece of your business the way you think you do.

Our standing practice is that the client is the account owner from the first day and we are the collaborator, not the reverse. The Doggy Den site we built runs today under a care plan we maintain, and the ownership arrangement would look identical if they moved on tomorrow. As You Wood is the same shape: we completed the website work and continue on ecommerce SEO, with the accounts in their name throughout. A care plan is a service, not a hostage arrangement, and the difference between the two is visible in whose email address appears on the hosting invoice.

We are building a healthcare analytics dashboard for a residential treatment provider, and we are building a site for a private practice therapist here in Salt Lake City. Both were set up this way before any code existed, because retrofitting account ownership after launch is the kind of task that gets scheduled and never done.

Five things to check this week

None of these require a lawyer to begin.

1. Search your development agreement for the word assign. If the only ownership language you find is work made for hire, you have a gap worth one short conversation with counsel.
2. Ask who the owner is on the code repository. Not who can push to it. The owner or the organization administrator.
3. Log in to your domain registrar yourself, today. If you cannot, that is the finding.
4. Ask for a current list of everyone with production access, then ask when it was last pruned.
5. Ask what happens on the last day. A one page exit plan naming the accounts, the export formats, and the timeline is a reasonable thing to request and a quick thing to write.

If your developer answers all five without going quiet, you are in better shape than most. That is useful to know either way.

Frequently asked questions

Does this mean AI written code is not worth owning? It means ownership rests more on contract and secrecy than on copyright. Most small business software was never going to be defended in a copyright suit anyway. What you need is the ability to keep running it, change it, and stop someone else walking off with it.

Should I ask my developer which parts were AI generated? Ask about the approach rather than a line by line accounting, which nobody can honestly produce. What you want to know is whether generated code gets reviewed and reshaped or pasted, because that single answer settles both the authorship question and the quality question.

I signed a contract years ago and there is no assignment clause. Now what? A confirmatory assignment is usually a short document and an easy ask while the relationship is good. It becomes a much harder ask after a disagreement, which is the whole argument for handling it now.

Does a monthly care plan mean the agency owns my site? It should not, and checking takes two minutes. Look at who the registrar and hosting accounts belong to. Maintenance is a service you can stop buying. If stopping means losing your domain, that was never maintenance.

We are replacing an old system. When does ownership come up? At the start, not at the handoff. Getting accounts and assignment right before migration is far cheaper than untangling it midway, which shapes how we approach replacing systems a business already depends on.

If you are not certain what your agreement covers, send us the scope and the ownership language and we will tell you what it reaches and where it stops. That review is where most of our custom software engagements begin.

Have your agreement reviewed