IP Transfer Agreement for Developers: Why “Work for Hire” Isn’t Enough

If a developer, in-house, freelance, or a co-founder, has ever written code for your startup without a signed IP Transfer Agreement, there’s a real chance your company doesn’t legally own that code. Not “might have a weak claim to it.” Doesn’t own it.

This catches founders off guard because most people assume paying someone for work automatically means you own what they built. Under US law, that assumption is wrong more often than founders realize.

What an IP Transfer Agreement Template Actually Covers

An IP Transfer Agreement (also called an IP Assignment Agreement) is a contract where a developer formally assigns ownership of the code, designs, and related intellectual property they create to your company. A solid one covers:

• A clear description of what work is being assigned (the specific project, codebase, or scope)
• An explicit present-tense assignment of rights, not just a promise to assign later
• Carve-outs for any pre-existing IP the developer brings in, like personal libraries or prior tools
• A waiver of moral rights, which exist separately from ownership in many jurisdictions
• Coverage for future improvements and derivative work built on the original assignment

Every one of these matters. Missing even one has caused real disputes over who owns what once a product has value.

Why “Work for Hire” Doesn’t Automatically Apply

This is the part that trips founders up most. Under US copyright law, work created by an employee within the scope of their job is automatically “work made for hire,” owned by the employer without any extra paperwork.

Work created by an independent contractor is different. It only counts as work for hire if the work fits into one of a narrow, specific list of categories defined by the Copyright Act, and even then, only if there’s a signed written agreement saying so. Custom software generally does not fall neatly into that list.

In plain terms: if you hired a freelance developer, contracted a dev shop, or brought on a technical co-founder who isn’t formally an employee, and you don’t have a signed IP Transfer Agreement, the default legal position is that the developer, not your company, owns the copyright in the code they wrote.

Employee vs. Independent Contractor: Default Ownership

That last row surprises people the most. Co-founders assume shared ownership of the company means shared ownership of what they built together. Legally, it doesn’t, unless it’s documented.

A Quick Example

A startup contracts a freelance developer to build its MVP. No IP Transfer Agreement is signed, just an informal scope-of-work email and a series of invoices. Eighteen months later, the startup is raising a seed round, and due diligence flags that the company can’t show clean ownership of its core codebase.

The company now has to track down the original developer, who may or may not still be reachable, cooperative, or willing to sign without renegotiating. In the worst version of this, the round is delayed or the developer uses the leverage to ask for money, equity, or both, to sign something that should have taken five minutes at the start of the engagement.

None of this happens to companies that get the agreement signed before the first line of code is written.

What About Open-Source and Third-Party Code?

Most real-world codebases aren’t written entirely from scratch. Developers use open-source libraries, npm packages, and third-party frameworks as a matter of course. An IP Transfer Agreement needs to account for this directly, not pretend it doesn’t happen.

A well-drafted agreement should require the developer to disclose any open-source or third-party components used, and confirm those components are licensed in a way that’s compatible with a commercial product (some open-source licenses, like certain copyleft licenses, place real restrictions on how code built with them can be used or sold). Without this, a startup can end up owning code that legally can’t be used the way it’s being used, which is a very different problem to discover during due diligence than a missing signature.

Why This Matters More for Cross-Border Teams

If you’re a founder in Nigeria hiring developers locally, remotely, or through a dev shop, to build a product for a US-incorporated company, a few things raise the stakes further:

Jurisdiction adds ambiguity. Whose IP law applies, the developer’s country or the company’s country of incorporation, is exactly the kind of question you want answered in the contract, not left to be argued later.

US investors will ask for this specifically. IP ownership is one of the standard items in early-stage due diligence, and “we paid them so we assumed we owned it” is not an answer that satisfies a diligence checklist.

Verbal or informal arrangements are common early on, and risky. Many early hires happen through personal networks, WhatsApp conversations, and handshake understanding. That’s exactly the setup where nobody thinks to formalize IP assignment until it’s needed for a deal.

Common Mistakes Founders Make Here

• Assuming a work-for-hire clause alone is enough, without an actual present-tense assignment of rights
• Not getting agreements signed with technical co-founders, because “we’re all in this together” feels like it should cover it
• Skipping the pre-existing IP carve-out, which creates disputes over what the developer already owned versus what they built for you
• Treating this as something to clean up later, once the company is raising or being acquired, when leverage has shifted away from the company

Getting an IP Transfer Agreement Without the Legal Bill

An IP Transfer Agreement doesn’t need a custom drafting engagement for every developer you bring on. If you’re incorporating in the US, an IP Transfer Agreement template built for developer and technical hires gives you the present-tense assignment language, moral rights waiver, and pre-existing IP carve-out already in place.

It’s part of the same document bank for founders incorporating in the US as our Co-Founder Agreement and Share Vesting Agreement templates, built to work together as one clean set of founder and IP documentation rather than pieced together from different sources.

FAQ

Does this apply to a technical co-founder, or just outside contractors?

Both. Unless a co-founder is a formal employee of the company, their default legal ownership of what they build is the same as a contractor’s. Founders should sign this alongside their Co-Founder Agreement, not instead of it.

What if the developer already signed a work-for-hire clause?

A work-for-hire clause helps, but for independent contractors it often isn’t sufficient on its own under US copyright law. A present-tense IP assignment covers the gap a work-for-hire clause can leave open.

Do I need this for developers based outside the US?

Yes, if the company is US-incorporated or the product is being built for a US entity. The agreement should specify which jurisdiction’s law governs it, which matters more, not less, when the developer and company are in different countries.

What about code a developer wrote before working with us?

That’s exactly what the pre-existing IP carve-out is for. It lets the developer keep ownership of tools, libraries, or code they already had, while still assigning ownership of the new work built for your company.

What if the developer used open-source libraries in the build?

That’s normal and expected, but the agreement should require disclosure of what was used and confirmation that the licenses are compatible with commercial use. Some open-source licenses come with restrictions that can limit how the resulting product can be sold or distributed.

The Bottom Line

Paying a developer doesn’t automatically mean you own what they built. A signed IP Transfer Agreement is what actually makes that true, and it’s far cheaper and faster to get signed before work starts than to untangle after your company has something worth fighting over.

If you’re incorporating in the US and want your IP ownership documented properly from the first hire, start here.