IPLegal

How to Protect Your IP When Working with Freelancers or Agencies

Every line of code, design, or system written by a contractor could legally belong to them — not you — if the paperwork isn't right. Here's what you need in place before work starts.

Problem

Payment doesn't transfer ownership

In most jurisdictions, copyright in a creative work belongs to the person who created it — not the person who paid for it. This surprises most founders because the intuition around employment is different: when an employee builds something on company time with company resources, the company owns it. That rule doesn't automatically extend to independent contractors. A freelancer who writes your authentication module, designs your onboarding flow, or builds your data pipeline owns that work by default until they explicitly transfer it.

The “work for hire” doctrine exists, but it has narrow requirements. In the US, a work qualifies as work for hire under the Copyright Act only if it falls into specific enumerated categories (like a contribution to a collective work, a compilation, or an instructional text) and there is a written agreement saying so. Most software code doesn't fall neatly into those categories — which means the work-for-hire label in a contract, without an explicit IP assignment clause, may not accomplish what you think it does. Many founders sign agreements that include work-for-hire language and assume they're protected. They often aren't.

The practical consequence surfaces at the worst possible time: during a funding round or acquisition, when a buyer's lawyer runs a title search on your IP and finds that three contractors who built core parts of your system never signed assignment agreements. At that point you're either tracking down people who may not want to be found, negotiating under time pressure, or discounting the deal to cover the risk. All of it was preventable with a one-page document signed before work started.

Requirements

The three documents that actually matter

You need three things covered before a contractor touches anything substantive: an IP assignment agreement, a work-for-hire clause, and an NDA. The IP assignment agreement is the most important — it says that any work product the contractor creates in the scope of this engagement is assigned to the company. The work-for-hire clause attempts to classify the work as company property under copyright law. You want both because they operate through different legal mechanisms, and courts don't always agree on which one applies in a given situation. The NDA covers what the contractor can share externally and protects your confidential information during the engagement.

Jurisdiction matters more than most founders realize. The defaults in the US, UK, India, and most of Western Europe differ in meaningful ways. A contractor in Germany, for example, has moral rights in their work that can't be fully assigned away under German law — you can get an exclusive license, but not absolute ownership. A developer in India working through a US company is governed by Indian copyright law for the work they actually create. Before you use a boilerplate contractor agreement from an American legal forms site with a contractor in another country, have a lawyer confirm it's enforceable in their jurisdiction. A $200 review now is worth more than a $20,000 dispute later.

Process

What to do before, during, and after an engagement

Before any work starts, get a signed contractor agreement in place that includes all three elements: IP assignment, work-for-hire provision, and NDA. Don't start the clock on a project, share access to your codebase, or pay a deposit until this document is signed. The contractor who says “we can sign paperwork after I get started” is not necessarily acting in bad faith — but you should hold the line regardless. Every day of work that happens before a signed agreement is a day of work that exists in a legal gray zone.

When working with agencies, the contract needs to go one level deeper. The agency assigns IP to you in your contract with them — but whether they can actually make that assignment depends on whether the individual developers working on your project have assigned IP to the agency. Most reputable agencies have employment agreements or contractor agreements with their staff that cover this. Ask for confirmation. You're not being difficult — any buyer or investor will ask the same question during due diligence, and you want to be able to answer it cleanly.

After a long or complex engagement ends, consider getting a written confirmation of assignment even if you have the original agreement. This is especially useful if the scope expanded significantly beyond the original statement of work, if the contractor created anything that wasn't explicitly listed in the agreement, or if you're approaching a fundraise or exit. A simple letter confirming “all work product created during the engagement is assigned to [Company]” with a signature costs almost nothing and eliminates ambiguity.

Structure

The three IP mistakes that show up in due diligence

The most common mistake is no written agreement at all. This happens most often with contractors who are friends, with early work done before the company was formally incorporated, or with small gigs where the founder assumed the amount of money involved made formal paperwork unnecessary. The amount of money is irrelevant. A freelancer who wrote one critical module for $500 and never signed an assignment agreement technically owns that code. If it's load-bearing, fixing this retroactively is your problem, not theirs.

The second mistake is a payment-only arrangement — where there's an invoice, a bank transfer, and maybe a brief email thread, but no contract. This is surprisingly common. Founders treat the payment as implicit acknowledgment of ownership. Legally, it's not. A payment record establishes that you paid for something; it says nothing about what you own. The third mistake is a generic NDA that covers confidentiality but has no IP assignment clause. These are widely available online and look official. But an NDA only protects information — it doesn't transfer ownership of work product.

In a due diligence process, a technical or legal team will look at every material contributor to your codebase and ask whether you have signed IP assignment documentation for each one. Missing documentation on a core system component is a red flag that can result in a price adjustment, an escrow holdback, or a requirement that you resolve the issue before closing. Don't wait for that conversation to learn you have a gap. Run the check yourself, now, while the people involved are still reachable.

Learn this properly, not just for one decision

In-depth courses and books that teach you to think like an engineer — not a one-off answer you'll need to look up again next time.

Frequently asked questions

Can I fix IP assignment issues retroactively?

Sometimes — but it depends on whether you can locate the contractor, whether they're willing to sign, and whether any other parties have acquired an interest in the work since. Retroactive assignments are legally valid in most jurisdictions, but getting a freelancer who moved on two years ago to sign a document takes time and sometimes negotiation. Courts have also occasionally found that a pattern of behavior (deploying the work, paying for it, treating it as yours) supports an implied license, but an implied license is not ownership. If you have gaps, a lawyer should review which ones are material and which ones can be papered over before a deal surfaces them.

Does an NDA cover IP ownership?

No. An NDA (non-disclosure agreement) covers confidentiality — it restricts what a contractor can share with third parties. It says nothing about who owns the work product. You can have a perfectly airtight NDA and still have no ownership rights over the code or designs the contractor built. IP ownership requires a separate clause — an IP assignment provision or a work-for-hire designation — in the contractor agreement. Treat them as two distinct legal instruments that happen to live in the same document.