Who owns the code you paid for?
A founder’s guide to code ownership in 2026 — what “work for hire” actually covers, why it usually isn’t enough when you hire a developer, and exactly what to put in the contract instead.
You hired a developer, paid the invoices, and now you’re using the software in your business. It feels like yours. Legally, it might not be.
In 2026, one of the most common — and most expensive — mistakes founders make in a development contract is assuming that paying for software is the same thing as owning it. It isn’t, and the gap between what you think you bought and what the law actually granted you is exactly the kind of thing that surfaces at the worst possible moment: during a fundraise, an acquisition, or a falling-out with the developer who built your product.
This guide walks through what “work for hire” actually means, why it usually doesn’t do what founders assume, and exactly what to put in your contract so that when someone asks “do you actually own this?” the answer is yes, in writing.
Story.law by Story LLP builds these protections directly into the agreement generator it offers founders, so you can get a court-ready contract before your developer writes the first line of code.
Does paying a developer mean you own the code?
Not automatically, and this is the single most important thing to understand before you hire anyone to build software for your company. Under U.S. copyright law, the person who writes the code owns it the moment it’s created — full stop. That default doesn’t change because you paid a deposit, signed a purchase order, or the word “hired” appears anywhere in your emails.
Ownership transfers to you only through one of two legal mechanisms: a statutory work-made-for-hire relationship, or a written assignment signed by the developer. Absent one of those, what you actually have may be a license — permission to use the software — while the developer retains the underlying copyright. That distinction sounds technical until it’s the reason a due diligence review flags your company’s core product as a legal risk.
The default
The person who writes the code owns it, from the moment it is created.
Only two things change that
Route one
Statutory work made for hire
Only an employee within the scope of employment, or one of nine narrow commissioned-work categories.
Route two
A written assignment
Signed by the developer, transferring all right, title, and interest to your company on a defined trigger.
Neither one in your contract? What you have may be a license — permission to use the software, while the developer keeps the copyright.
Why “work for hire” in your contractor agreement might not protect you
Nearly every template contract includes a line about “work made for hire,” and founders reasonably assume it means the company owns whatever the contractor builds. In most cases involving independent contractors, it doesn’t. Under 17 U.S.C. § 101, a work only qualifies as made for hire in two situations.
Situation one
An actual employee
Work created by a real employee, within the scope of their employment. Most of the people building your product are not employees — they are freelancers, contract teams, or agencies.
Situation two
One of nine narrow categories
Specially commissioned work that falls into one of nine statutory categories — things like contributions to a collective work, translations, or compilations. Custom software is not on that list.
This matters because most of the people building your product are independent contractors, not employees — a freelance developer, a contract team, or an agency. If your only ownership protection is a “work for hire” clause, and the deliverable doesn’t fit the statutory test, that clause may be legally empty. You could be the company that paid in full, deployed the product, and built a business on top of it — while the developer who wrote it still holds the copyright.
What this means for your company
Don’t treat “work for hire” language as sufficient on its own. Your contract needs a written assignment clause as a backup that transfers ownership to you directly, regardless of whether the work-for-hire category applies. Story.law’s agreement templates pair the work-for-hire recital with exactly this kind of fallback assignment by default, so the ownership question doesn’t depend on which of the nine statutory categories a court decides your software falls into.
Related reading: Independent contractor vs. W-2 employee — how the same employee-or-contractor line that decides your tax exposure also decides whether work for hire can apply at all.
Work for hire, assignment, or license: what are you actually getting?
Before you sign anything, know which of these three structures your contract creates — they produce very different outcomes for your company.
| Factor | Work made for hire | Copyright assignmentUsually the right structure | Perpetual license |
|---|---|---|---|
| Who legally owns the code | Your company, from creation — but only if the narrow statutory test is actually met | The developer creates it; ownership transfers to your company on a defined trigger, typically full payment | The developer keeps ownership permanently; your company only has permission to use it |
| Your right to modify, extend, or resell | Unlimited, if it applies | Unlimited once the assignment vests | Limited to whatever the license agreement specifically permits |
| What it costs your company | Highest expectation — you’re expecting to own everything, but the legal basis may be missing | Moderate — the price should reflect a full, permanent ownership transfer | Lower upfront — you’re paying for use, not for title |
| Your risk if the clause is wrong | High — most contractor arrangements don’t actually qualify, so you may not own what you think you own | Low, if the assignment is properly drafted with a clear trigger | Medium — if usage rights aren’t defined precisely, disputes arise over what you’re actually allowed to do with the software |
| What happens if the developer disappears or won’t cooperate later | Ownership question may be unresolved if work for hire didn’t apply | Clean — you hold title outright once the assignment has vested | Your rights depend on the license terms continuing to be honored, which can be a real gap if the developer’s business changes hands |
Three structures a development contract can create. Scroll sideways to compare all three.
For a company that plans to raise capital, sell the business, or simply wants to be able to modify and extend its own product without asking permission, a properly triggered assignment is almost always the right structure — not a license, and not a work-for-hire clause standing alone.
The ownership gaps that show up in due diligence
Gap 01
“We paid for it, so we own it” is not a legal position.
This is the single most common misunderstanding founders bring into a diligence process. Payment settles an invoice. It does not, by itself, transfer copyright. If your contract never included a written assignment, the developer may still hold the copyright even though your company paid every invoice and has been running on the software for years.
Gap 02
A “work for hire” clause that doesn’t actually apply to your engagement.
If the developer is a genuine independent contractor and your deliverable is custom software — which is almost always the case — the statutory work-for-hire test likely isn’t met. A clause that says “work for hire” without a fallback assignment leaves your ownership status genuinely unresolved, and that ambiguity is exactly what a diligence reviewer is trained to flag.
Gap 03
Undisclosed open-source components buried in your codebase.
If a developer incorporated GPL- or AGPL-licensed code into your product without telling you, your company may have inherited a copyleft obligation — potentially requiring you to make your proprietary source code available. This is a common and expensive surprise during an acquisition or funding round, because it’s rarely caught until someone runs a formal license audit.
Gap 04
No record of what the developer brought versus what they built for you.
Developers often reuse frameworks, libraries, or tools across every client. If your contract doesn’t distinguish what was custom-built for your company from what the developer is licensing to you, you may not actually have the unrestricted rights you assumed — and neither party may remember, years later, which is which.
Gap 05
A vendor relationship that ended before ownership was ever confirmed in writing.
If a developer relationship ended on good terms or bad, and no one formally executed the assignment at the time, your company may be sitting on a gap in its chain of title that only becomes visible when a buyer’s lawyers go looking for it.
Story.law’s agreement generator is built to close each of these gaps before they become due diligence findings: a conditional assignment with a specific trigger, a background IP disclosure that shows you exactly what the developer is and isn’t transferring, and an open-source disclosure requirement built into the contract itself.
Related reading: Series A diligence: the three documents VCs want — IP ownership is one of them — and data rooms: Marie-Kondo your docs before diligence, which is where these documents get read.
What to put in your contract to actually own what you’re paying for
A written assignment clause, not just a “work for hire” label
The contract should include an express, present-tense assignment of copyright — language that says the developer assigns all right, title, and interest in the deliverables to your company, effective on a specific trigger. Don’t rely on “work for hire” alone; require the assignment as a backup regardless of whether that label technically applies.
A clear, specific trigger for when ownership transfers
The assignment should vest on a defined, unambiguous event — typically full payment. Avoid vague triggers like “upon completion” or “upon delivery,” which can create disputes about exactly when ownership passed and whether it passed at all.
A background IP disclosure, so you know what you actually got
Ask the developer to identify, in writing, any pre-existing code, libraries, or tools they’re bringing into your project rather than building fresh. This isn’t a red flag — it’s normal and often improves quality — but you need to know whether those components are being assigned to you outright or licensed to you as part of the deliverable, and get a clear, perpetual right to use them as part of your product either way.
An open-source disclosure requirement, confirmed before you sign
Require the developer to disclose every open-source component in the deliverable and the license governing each one, before or at signing. Prohibit incorporation of copyleft-licensed components — GPL, AGPL — without your prior written approval. This is the single easiest way to avoid a compliance surprise during a raise or exit.
A cooperation clause that survives the end of the engagement
If you later need the developer to sign additional documents — to register the copyright, perfect the assignment with the U.S. Copyright Office, or support a patent application — a cooperation clause obligates them to do it, even years after the project wrapped, without reopening the whole relationship.
A repository and delivery clause
Owning the copyright to code you can’t actually access is a legal position, not a practical one. Confirm in writing where the code lives, who controls repository access, and what happens to that access when the engagement ends.
What to ask a developer before you sign
Before you sign any development agreement, it’s worth asking the developer these questions directly — the answers tell you a lot about how the ownership conversation is going to go later.
“Will the contract include a written assignment, not just a work-for-hire clause?”
A developer who understands IP law will say yes without hesitation — this is standard, not confrontational. Hesitation here is worth exploring further.
“Are you bringing any of your own pre-existing tools or libraries into this build?”
This is a completely normal thing for a developer to do, and it’s a sign of experience, not a red flag. What matters is that it’s disclosed and that you get clear usage rights to whatever they bring in.
“Does your codebase use any GPL or AGPL-licensed components?”
If the answer is yes, ask what the implications are for your ability to keep your source code proprietary — and get that answer in writing before the project ships, not after.
“When exactly does ownership transfer to us — at delivery, at acceptance, or at final payment?”
The answer should be specific and should match what’s written in the contract. If the developer’s verbal answer and the contract language don’t match, that’s worth resolving before you sign.
How founders use these structures in practice
Building a fundable, sellable product from day one
If your company plans to raise venture capital or eventually sell, you need to own your codebase outright, with no ambiguity. The right structure is a conditional assignment that vests on final payment, combined with a background IP disclosure that shows exactly what pre-existing components the developer brought in and confirms you have a clear right to use them as part of your product. Investors and acquirers will run IP due diligence, and unclear ownership can reduce your company’s valuation or derail a transaction entirely.
Working with an agency that reuses its own framework
If your agency builds your product on top of a proprietary framework they use across many clients, expect a partial-assignment structure: you own the custom code built specifically for you, and you receive an irrevocable license to use the underlying framework as incorporated in your product. This is normal and doesn’t diminish what you own — but confirm the license is perpetual and can’t be revoked or altered later.
Catching an open-source problem before it becomes an acquisition problem
If your developer used an AGPL-licensed component for a good technical reason, the open-source disclosure requirement should surface it before the project ships — giving you the chance to approve it, ask for a substitute, or obtain a commercial license, while it’s a cheap fix instead of a deal-threatening discovery during diligence.
Why this matters for your company’s value
Clean title makes your company fundable and acquirable. Every serious investor and acquirer runs IP due diligence on the technology they’re buying into. A codebase with a documented, unambiguous chain of title — clear assignments, disclosed open-source components, no reliance on a work-for-hire clause that may not apply — is a straightforward asset to value. A codebase where ownership is uncertain can reduce your valuation, trigger a remediation requirement, or kill a deal outright.
A cooperation clause protects you long after the project ends. Ownership perfection sometimes requires additional paperwork years after a project wraps — registering a copyright, supporting a patent filing. Without a cooperation clause, tracking down a developer who’s moved on to get a signature can become its own project.
Open-source disclosure protects your ability to stay proprietary. Industry research has repeatedly found open-source license conflicts in a majority of audited commercial codebases. Requiring disclosure upfront and building in an approval right gives you the chance to address a conflict before it becomes a material issue at a funding round or exit — rather than discovering it when a buyer’s counsel does.
Getting this right once saves you from renegotiating your own history. A company that has to go back to a former developer years later to fix a missing assignment is negotiating from a position of weakness. Getting the assignment right at signing means you never have that conversation.
How Story.law simplifies code ownership for founders
Story.law by Story LLP is built for founders and companies who hire developers and need to know, with confidence, that they actually own what they’re paying for. The platform walks you through the ownership questions that matter before you sign: whether your engagement even qualifies for work-for-hire treatment, how to structure an assignment that’s specific and enforceable, what to ask about pre-existing code the developer is bringing in, and how to handle open-source disclosure so it doesn’t become a surprise later.
The agreement generator produces a document specific to your engagement — not a generic template — with:
The fallback assignment language that closes the work-for-hire gap.
A background IP disclosure that shows you exactly what you’re getting.
A cooperation clause that protects you if you need the developer’s signature again down the road.
Story LLP’s attorneys designed the underlying clause library. The platform makes it accessible to any founder who needs a court-ready agreement before a project starts, at a fraction of the cost of a bespoke legal engagement.
Generate your agreement on Story.law before your next project starts.
FAQs: code ownership for founders hiring a developer
If I pay a developer, don’t I automatically own the code?
No. Payment settles an invoice; it does not, by itself, transfer copyright. Ownership only transfers to your company through a statutory work-made-for-hire relationship or a written assignment signed by the developer. Without one of those in your contract, the developer may retain the copyright even after you’ve paid in full and are actively using the software. Story.law’s agreement templates include an express written assignment as a backup to any work-for-hire language, so ownership doesn’t depend on an assumption that turns out to be wrong.
Does a “work for hire” clause in my developer contract mean my company owns the software?
Not necessarily. Under 17 U.S.C. § 101, work made for hire only applies to actual employees, or to commissioned work that fits into one of nine narrow statutory categories — and custom software generally isn’t one of them. If your developer is an independent contractor, which is the case in most freelance and agency engagements, a work-for-hire clause alone may not transfer ownership. Your contract needs a written assignment as a backup. Story.law builds this fallback assignment into its agreements by default.
What should I ask my developer for to make sure my company owns the code?
Ask for three things in the contract: a written, present-tense copyright assignment (not just a “work for hire” label) with a specific trigger tied to full payment; a disclosure of any pre-existing code, libraries, or tools the developer is bringing into the build, with clear usage rights granted to your company; and an open-source disclosure requirement that identifies any third-party licensed components before the project ships. Story.law’s agreement generator includes all three as standard provisions.
How do I know if I have a real ownership stake in my product or just a license to use it?
Check what your contract actually says, not what you assumed. If the contract only says “work for hire” and doesn’t include an express assignment clause, and your deliverable doesn’t fit one of the nine statutory work-for-hire categories, you may hold only an implied license rather than ownership. A license means the developer retains the copyright and you have permission to use the software under whatever terms were agreed — which is a materially weaker position for fundraising or an exit than outright ownership. If you’re not sure which you have, that uncertainty is itself worth resolving before it surfaces in a due diligence review.
Why does code ownership matter for fundraising or selling my company?
Investors and acquirers run IP due diligence on every technology transaction. A codebase with a clean, documented chain of title is straightforward to value. A codebase where ownership depends on a work-for-hire clause that may not legally apply, or where open-source components were never disclosed, introduces risk that can lower your valuation, require costly remediation before a deal can close, or derail the transaction entirely. Confirming clean ownership before you need it, rather than during diligence, is significantly cheaper and faster.
What are open-source license risks, and why should I care as a non-technical founder?
If your developer incorporates code governed by a “copyleft” license, such as the GPL or AGPL, into your proprietary product without disclosing it, your company may inherit an obligation to make your own source code publicly available under similar terms. This is a real and common risk, and it’s rarely caught until someone runs a formal audit — often during a funding round or acquisition. Requiring open-source disclosure and prior written approval for any copyleft component in your development contract is the simplest way to prevent this from becoming a surprise later.
What’s the difference between a license and an assignment, and which one do I want?
An assignment permanently transfers copyright ownership to your company — you hold title outright, and your rights don’t depend on any ongoing agreement. A license only grants permission to use the software; the developer keeps ownership, and your rights depend on the license terms continuing to be honored, including through any change in the developer’s business. If you’re building your company’s core product and plan to raise capital or sell the business, you want an assignment. A license can be appropriate for a component you’re using but didn’t need to own outright — but know which one your contract actually gives you.
We're lawyers, remember? Please read this important note:
Story LLP is a law firm, and Story's lawyers built Aegis to deliver better, standard legal services at scale so founders can choose between top-tier specialized lawyers and standardized process automations that replicate those lawyers according to their needs and budget. By definition, a standardized process may not be perfect for you. Please review our Policies page to better understand the difference, as well as how we use AI and how we manage conflicts, privilege, etc.
As a law firm, we must screen clients for conflicts of interest, and we treat all correspondence with clients seeking legal advice as privileged and confidential to the maximum extent possible in consideration of any conflicts. However, Story's law firm or our Attorney Allies do not represent you or your company as your lawyer, do not have an attorney-client relationship with you or your company, and do not provide you with legal advice absent a formal Engagement Letter signed between you and the Story LLP law firm. Please don't confuse the free knowledge we offer on this site with legal advice for you.