Who owns the code a contractor writes for your startup? By default, the contractor does. Consider the standard story: a founder hires a freelance developer to build the first version of the product. Money changes hands, the app ships, the company grows. Two years later an investor's diligence team asks a simple question: can you show that the company owns the code? And the founder realizes, for the first time, that they cannot. The developer signed no assignment, and under the default rule, the developer still owns what they built. That is not an edge case. It is one of the most common and most expensive gaps in early-stage companies.
The belief that "if I paid for it, I own it" is the single most dangerous misconception in startup law. It feels obviously true and it is legally false. This guide explains who actually owns the intellectual property behind your product, why the wrong assumption can cost you a round or a deal, and the exact language that fixes it. For the broader ownership and contracts layer, see startup contracts and founder equity strategy.
The default rule that surprises founders
Under US copyright law, the person who creates a work owns it the moment it is fixed in a tangible form, code committed to a repository, a design saved to a file, copy written into a document. Ownership starts with the creator, not with whoever paid. For independent contractors, there is no automatic transfer to the company simply because a check was cashed. The contractor owns what they made unless a signed agreement says otherwise.
So when a freelance developer writes your MVP, a contract designer names and styles your product, or an outside agency builds your data pipeline, the default is that they hold the copyright, and your company holds a bill. The work is yours to use in the everyday sense, but the underlying ownership, the thing an investor or acquirer is actually buying, may sit with someone who is no longer answering your emails.
Employees and contractors are not the same for ownership
Founders often assume the "work made for hire" doctrine solves this. It helps, but only for employees, and only within limits. Work created by an employee within the scope of their employment can qualify as work made for hire, which the company owns from the start. That is why the employee relationship is cleaner for IP than the contractor relationship.
For independent contractors, work made for hire applies only to a narrow set of specially commissioned categories, and software often does not fit neatly inside them. The reliable answer for contractors is not the doctrine; it is an explicit written assignment. This is also where worker classification quietly compounds the risk: a company that treats someone as a contractor to stay lean, then directs their work like an employee, can face misclassification exposure and still lack the clean IP assignment an employee would have signed. You can end up with the liabilities of both relationships and the ownership protection of neither. The fix is the same in both directions: get the classification right, and get the assignment signed regardless.
Payment buys the service. It does not buy the copyright. The only thing that moves ownership to the company is a signature on the right sentence.
The two words that decide ownership: "hereby assigns"
Not all assignment language works, and the difference is subtle enough that founders miss it even when a contract exists. The clause has to transfer ownership in the present tense. Language like "Contractor hereby assigns to the Company all right, title, and interest in and to" the work causes the assignment to happen automatically, by operation of law, the moment the IP is created.
Future-tense language does not do that. "Agrees to assign," "will assign," or "shall assign" is only a promise to transfer ownership later. It requires a further act, another signature, to complete, and if the contractor has vanished, changed their mind, or wants to be paid again, that promise can be difficult or impossible to enforce. Companies have lost ownership of critical technology on exactly this distinction. The single word "hereby" is often what stands between owning your product and merely being owed it.
Sign it before the work starts
Timing is the other half of the problem. The assignment should be signed before the contractor begins, not bolted on afterward. A pre-work agreement establishes ownership cleanly from the first commit. A retroactive assignment signed months or years later is better than nothing, but it invites questions: what was the consideration, did the contractor have leverage to renegotiate, did anything get created in the gap. Diligence teams notice retroactive paper, and they price the uncertainty. The cheap version of this fix costs one signature at the start of an engagement. The expensive version is chasing a former contractor during a live deal.
The full chain of title, not just contractors
Owning your product means everyone who touched it assigned their work to the company. Diligence follows that chain link by link, and a single missing link is enough to create a problem. At minimum, get signed IP assignment from:
- Founders. Especially work done before incorporation. Pre-formation code and designs need to be assigned into the company, or the company may not own its own origins.
- Employees. Through a proprietary information and inventions assignment (a PIIA) signed at hire, rather than relying on work made for hire alone.
- Contractors and freelancers. Present-tense assignment, signed before work begins, covering code, designs, and deliverables.
- Advisors and agencies. Anyone who contributes IP, including outside dev shops, branding firms, and technical advisors, assigns what they create.
The document that carries most of this for a company's own people is the PIIA: it assigns inventions and work product to the company and protects confidential information. For everyone outside the company, the assignment lives in the contractor or vendor agreement. Either way, the goal is the same, a clean, unbroken line from every contributor to the company.
Open source and the AI wrinkle
Two modern issues complicate the chain further. First, open-source components carry their own license terms, and some are permissive while others impose obligations that can affect how you distribute or license your product. Owning your own code does not free you from the terms of the code you built on. Second, AI-assisted development and model-generated output raise fresh questions about what is protectable and who holds rights in it. A team using coding assistants and foundation models should understand what the tool's terms say about ownership and use, so the company's promises to customers do not outrun the rights it actually holds. This overlaps directly with your model-provider and vendor terms and your AI compliance posture.
Why this shows up as a deal-killer
For most startups, the intellectual property is the asset. It is what investors fund and what acquirers buy. So when diligence finds a gap in the chain of title, it is not a paperwork nuisance; it goes to the core of what is being purchased. Missing contractor assignments are one of the most frequent reasons a deal is delayed, re-priced, or refused outright, and even a fixable gap can trigger a holdback that keeps part of the money out of your hands until it is resolved. The founders who breeze through IP diligence are not lucky. They collected the signatures as they went, so the chain was already clean when someone finally checked.
- Paying for work does not transfer ownership. By default, the contractor owns what they create.
- Use present-tense "hereby assigns" language. Future-tense "will assign" is only a promise and can fail.
- Sign the assignment before the work begins, not retroactively during a deal.
- Build the full chain of title: founders, employees (PIIA), contractors, advisors, and agencies.
- Mind open-source license terms and the ownership terms of any AI tools in your stack.
The move here is boring and decisive: use the right assignment language, get it signed before work starts, and collect it from everyone who touches the product. That is the whole discipline, and it is exactly the kind of upstream work where an hour of judgment saves a quarter of cleanup. If you built your first version with freelancers or an agency and have never confirmed the company owns it, that is worth checking now, while it is cheap, rather than during a round.
See how ownership fits a full startup legal due diligence checklist, read how IP assignment shows up when splitting equity with co-founders, or start a conversation about your chain of title. The other half of the contractor question, whether the person should be a contractor at all, is covered in contractor vs employee classification, and the license layer of the same question in open-source AI license compliance.