Who owns the code when you hire a developer.

Two things before the first legal word. I’m a developer, not a lawyer, and nothing here is legal advice. It’s how I structure my own contracts, and what I’d check in anyone else’s. And the reason this entry exists: “do I actually own the code?” is one of the two questions I hear on almost every first call. The answer under US law surprises most owners, because the default runs the opposite way from common sense. You can commission a build, approve every invoice, pay every dollar, and own none of it.

§1The default is not what you think

Copyright belongs to the person who creates a work, from the moment they create it. No registration, no paperwork — under the Berne Convention, protection is automatic in nearly every country on earth. A developer typing code is creating a copyrighted work, keystroke by keystroke, and the copyright lands on the author. Not on the person paying.

The rule is old, and it isn’t about software. The photographer who shoots your wedding owns those photos unless the contract says otherwise. Same law, same logic, same surprise.

US law carves out one big exception: the “work made for hire” doctrine. It has exactly two doors. Door one: the creator is your employee, working within the scope of their job. Then the employer owns the work automatically. Door two is narrower. The work is specially commissioned from an outside party. There’s a signed agreement calling it a work made for hire. And the work fits one of nine categories that the statute lists by name — a contribution to a collective work · part of a movie or audiovisual work · a translation · a supplementary work · a compilation · an instructional text · a test · answer material for a test · an atlas.

Read that list again. Software isn’t on it. Neither is a website, an app, or a database. Congress wrote those nine categories in 1976, and commissioned source code doesn’t fit them. For a freelancer or an outside studio, the work-for-hire label usually has nothing to attach to. A contract that just declares “this is a work made for hire” and stops there is, for most software, decoration.

So the default, stated plainly: your employee’s code is yours. Your contractor’s code is theirs, no matter how much you paid, until a written assignment says otherwise. The invoice buys the work. It does not buy the rights.

§2What you hold without a clause

If the contract is silent, you usually aren’t left with nothing — you’re left with something worse than nothing: an undefined something. Courts often find an implied license: you paid for the software to be built for you, so you can presumably use it. What that implied license covers is exactly as clear as the word “presumably.” Can you modify the code? Hire a different developer to extend it? Copy it into a second location? Sell it with the business? Every one of those is a maybe, and each maybe is answered later, under pressure, at legal rates.

Owners rarely feel this gap during the build. They feel it at three specific moments. When they switch developers, and the old one asserts the code can’t be handed to the new one. When they sell the company, and the buyer’s due-diligence lawyer asks who owns the software the business runs on — and no document answers. And when the relationship sours, and the developer’s bargaining position turns out to be written into copyright law rather than the contract. None of those moments is a good time to learn the word “implied.”

Run the arithmetic on that gap once. A $12,000 build you can’t legally extend is a $12,000 sunk cost plus the price of a rebuild. The ownership paragraph skipped at signing ends up costing more than the software did.

The fix costs one paragraph, signed before the work starts. Which brings me to the paragraph.

§3The sentence that fixes it

The instrument that actually moves ownership is an assignment: a written transfer of the copyright itself, signed by the person who would otherwise own it. Here is the shape of the clause, phrase by phrase, because every phrase is load-bearing:

“Developer hereby assigns to Client all right, title, and interest, including copyright, in the deliverables created under this agreement. The assignment takes effect as each milestone is paid.”

• “hereby assigns.” Present tense, and the single most expensive two words in this field. “Hereby assigns” transfers now. “Agrees to assign” merely promises a transfer later — a promise someone has to remember to keep. A patent fight that reached the Supreme Court as Stanford v. Roche (563 U.S. 776, decided 2011) turned on exactly this. The Federal Circuit read one researcher’s “agree to assign” as a future promise, and a rival’s “do hereby assign” as an immediate transfer. The rival’s paper won. Lawyers have been quoting the two phrasings at each other since. If a contract you’re offered says “agrees to assign,” ask for “hereby.” It’s a one-word edit and any developer acting in good faith will make it.
• “all right, title, and interest.” Copyright is a bundle of separate rights — copying, modifying, distributing, displaying. This phrase takes the bundle whole, so nobody argues later about which stick you bought.
• “including copyright.” Names the main right out loud instead of implying it.
• “deliverables created under this agreement.” The scope. You’re taking what was built for you, the custom work. §4 and §5 cover what legitimately sits outside that line.
• “as each milestone is paid.” The timing, and it protects both sides. You’re never mid-project with nothing owned; I’m never fully assigned and unpaid. Watch for the harsher variant in §4.

One more practical note. Whoever’s template you sign, this clause reads the same, and you’re allowed to bring your own paragraph if a developer’s contract lacks one. Lawyers call it an IP assignment. You can call it the paragraph that makes the invoice mean something.

One paragraph. That’s the entire distance between owning your system and renting it from your own developer.

§4Three traps that survive a good clause

A clean assignment clause can still sit inside a contract that undoes it. These are the three patterns worth checking for by name:

• The toolkit carve-out with no list. Most contracts exclude the developer’s “pre-existing tools and materials” from the assignment, and that’s legitimate. I reuse deployment scripts and boilerplate across projects, and so does everyone. The trap is a carve-out with no inventory. If nothing is listed, everything can be claimed as toolkit after the fact. Your “100% ownership” develops holes shaped like whatever the developer later regrets assigning. The fix: the excluded items are named in an attachment, and anything unnamed is assigned. Bonus fix: whatever toolkit does remain gets you a permanent, irrevocable license to keep using it inside your system.
• The broken chain of title. An agency can only assign rights it actually holds. Suppose the code was written by the agency’s subcontractor: a freelancer three time zones away, with no assignment clause in their own contract. Then the agency never owned the copyright, and its assignment to you transferred a right it didn’t hold. You can’t see this from outside. You have to ask: who literally types the code, and does their contract assign it upstream? A one-person shop has the shortest possible answer to this question. It’s one of the few structural advantages of my size, and the whole claim fits in a sentence: the chain of title is one link.
• Everything hinges on the final invoice. Some contracts make the entire assignment effective only on final payment. It sounds symmetrical, until you walk through a scope dispute in week seven. You’ve paid 80% of the project and own 0% of the code. The disagreement over the last invoice is now a negotiation where your system is the collateral. Milestone-by-milestone transfer (pay for milestone two, own milestone two) keeps a disagreement about the end from reaching back and unwinding the middle.

§5The open-source footnote

Anyone who tells you that you’ll own 100% of the software, full stop, is skipping a footnote that deserves to be read aloud. Modern software stands on open-source components, and nobody owns those: not you, not me, not the agency quoting you six figures. Take React, the interface library that Meta maintains and much of the industry builds on. Its license file is one short page: MIT License, copyright Meta Platforms, “Permission is hereby granted, free of charge, to any person obtaining a copy of this software…” You don’t own React. You hold the same MIT license as everyone else on earth, which lets you use, modify, and ship it without paying anyone.

So here is what “you own the code” means with the footnote read out. The custom code written for your project, the part that encodes your business, is assigned to you outright. The open-source underneath is licensed to you on the same terms the whole industry builds on: permissive licenses like MIT for most of the stack. That’s the identical legal position of nearly every software company you can name, so it isn’t a defect. It’s just the true sentence, and vendors who say the false one are telling you something about their comfort with footnotes.

One caution earns its place here. License terms vary, and a family called copyleft (GPL is the famous name) attaches conditions when you distribute software containing it. For an internal web system, the kind I build, distribution rarely happens. But the honest handling is structural, not rhetorical. Every dependency and its license is listed in one file in the repo; in a Node.js project it’s called package.json. Your next developer, or your buyer’s lawyer, reads the full list in minutes instead of taking anyone’s word. And if that file means nothing to you, fine — its existence is the point. “Can I see the dependency list and its licenses?” takes any developer thirty seconds to answer well.

§6Rights on paper, code in hand

The assignment clause gives you rights. Rights without possession are a lawsuit waiting to be filed — real, but slow and expensive to use. Possession without rights is a bluff. You want both, and they arrive by different routes.

The paper route is §3. The possession route is logistics. The repository is created under your GitHub account before the first line is written, and I work in it as a removable collaborator. The full mechanics are in the handover entry. Put the two together and the worst-case scenarios go boring. A dispute mid-build? You hold every line written so far and own every paid milestone. A developer who vanishes? The code is already in your account, with docs beside it. A sale of the business? The chain of title is one contract and one attachment. The buyer’s lawyer bills fewer hours — possibly the only person who’ll regret this arrangement.

A habit worth stealing, whoever builds for you. Keep one folder: the signed contract, the toolkit attachment, and a note of where the repo and accounts live. That folder is your answer to the due-diligence email, written years early.

This is also why the ownership section on my homepage is written as contract clauses rather than slogans. Clause one: you own the code. Clause two: the data. Clause three: the roadmap. And the transfer line under them reads “what stays with me: nothing.” Those aren’t design flourishes. They’re the same commitments this entry just unpacked, stated where a first-time visitor can’t miss them.

§7When you don’t need to own it

Code ownership is the center of how I work, so believe me when I say it isn’t always worth buying:

• When renting genuinely fits. A SaaS subscription is a license, not ownership, by design. When the tool actually fits your process, that’s a fair trade: their servers, their maintenance, their problem. The cases where the trade stops being fair are counted out, in dollars, in the five-year cost entry.
• When your budget is under $5,000. My own pricing page says it: below that, a good off-the-shelf tool beats me. Owning custom code you couldn’t afford to build properly is worse than licensing something solid.
• When your own employee writes it. Then door one of §1 applies and the work-for-hire doctrine does its job automatically. The clause still worth adding to employment paperwork is “hereby assigns” for work outside the scope of employment. But that’s a lawyer conversation, not a developer one.
• When ownership is theater. Some vendors offer “full code ownership” of a system so tangled that no other developer would take it over. That’s a liability with a compliment attached. Ownership has value when it’s paired with the things that make it usable: a standard stack, documentation, and a handover. Paper alone isn’t the product.

§8The questions to email anyone

Five questions, sendable as one email, answerable by any developer or agency in ten minutes. What you’re listening for is in each answer.

• “Does your contract ‘hereby assign’ the work, or ‘agree to assign’ it?” The right answer contains the word “hereby” and no visible discomfort. §3 explains what the wrong phrasing cost at the Supreme Court level.
• “What’s excluded as your pre-existing tools — and can I see the list?” The right answer is a list, or an offer to write one into the contract. “Our standard framework components” with no inventory is trap one of §4.
• “Who literally writes the code, and do their contracts assign rights to you?” A clean chain of title, or a plain account of one. Silence about subcontractors is the loudest answer on this list.
• “When does ownership transfer — per milestone, or only at final payment?” Per milestone protects you both. “At final payment” isn’t evil, but now you know what week seven of a scope dispute looks like.
• “Where does the repository live during the build?” “In your account from day one” is the answer that makes half the other questions matter less. It’s also, verbatim, my answer.

My responses to all five are in writing where anyone can read them: this entry, the handover entry, and the contract clauses on the homepage. And the disclaimer from the top of the page, repeated where it counts. For a build in the $8,000-to-$40,000 range, an hour of a real lawyer’s time on the contract is the cheapest insurance in the project. Bring them the clause from §3 and the three traps from §4, and the hour will be a short one.

Next in this series: what happens if I disappear, the other question from every first call. It gets the same treatment — structure over reassurance. If you’re earlier in the process than contracts, start with how I scope a fixed-price build. The scope document written there is what §3’s clause means by “deliverables.”