IP Assignment Explained for Founders

Here is the fact that surprises almost every first-time founder: paying someone to write your app does not, by itself, make you the owner of the code. In the United States and most other countries, the person who writes software is the default legal owner of it, even after your invoice clears, unless a signed contract says otherwise. That single gap has stalled fundraising rounds, blown up acquisitions, and left founders unable to change developers without permission from the last one. This guide explains IP assignment in plain language, so you can read a contract, spot the missing clause, and make sure the thing you paid to build is actually yours.

What "IP assignment" actually means

Intellectual property, or IP, is the legal ownership of things you cannot physically hold: the source code, the design files, the database schema, the copy on your screens, sometimes the underlying idea if it is patented. When you commission software, that IP has to belong to someone. "IP assignment" is the act of transferring that ownership from the person who created it to you, in writing. An assignment says, in effect, "everything I make for you under this agreement becomes yours, completely and permanently."

The word that matters is transfer. Without an assignment, the rights sit with the author by default. With one, the rights move to you. That is the whole game. A founder who understands this one sentence is ahead of most people who sign development contracts.

The default rule that surprises founders

Copyright in software attaches automatically to whoever writes it, the moment they write it. The question is only who counts as the owner, and the answer depends on the relationship.

Employees are one case

Work created by a full-time employee inside the scope of their job usually belongs to the employer automatically, under the "work made for hire" doctrine. If you have a payrolled engineer, the code they write for you is generally yours by default. Most founders building an MVP, though, are not hiring employees. They are hiring contractors, and that changes everything.

Contractors are the trap

A freelancer, an agency, or an offshore studio is an independent contractor, not your employee. For contractors, the "work made for hire" rule does not apply the way founders assume. In the United States, custom software generally does not qualify as work made for hire automatically, which means the contractor keeps the copyright unless they sign it over to you. You can pay a freelancer in full, get your app, launch it, and still not legally own the code. The developer could, in theory, reuse it, license it to a competitor, or refuse to hand over the source. This is not a rare horror story; it is the default outcome when nobody puts an assignment clause in the contract.

This is exactly why the contract matters as much as the code. If you want the fuller picture of everything a development agreement should contain, we cover it in what to put in a development contract. IP assignment is one clause in that document, but it is the one most likely to be missing.

License versus assignment: know the difference

The most common way founders get short-changed is by receiving a license when they think they are getting ownership. The two words sound similar and mean very different things.

Some studios build products on top of their own internal framework or a proprietary "platform" and will only license you the result. That can be acceptable for a quick prototype, but for a real product it means you can never leave, never sell cleanly, and never fully control your own roadmap. For the custom code that makes your product yours, you want an assignment. A license belongs on the third-party pieces you did not commission, and nowhere near your core.

What a strong IP assignment clause contains

You do not need to draft this yourself, but you should be able to check that these elements are present. Run down the list before you sign:

1. A present-tense transfer of all rights. Language like "Developer hereby assigns to Client all right, title, and interest" in the work product. "Hereby assigns" is stronger than "agrees to assign later," which can leave a gap.
2. A broad definition of the work product. It should cover source code, object code, designs, documentation, and anything else created under the agreement, not just "the software" narrowly defined.
3. A backup license, just in case. Good contracts add that if any right cannot be assigned for legal reasons, the developer grants you a perpetual, worldwide, royalty-free license to it. This closes loopholes in different jurisdictions.
4. A waiver of moral rights. In some countries creators keep "moral rights" even after assignment. A clean clause has them waive these to the extent allowed, so nobody can object to how you modify or rebrand the work.
5. A "further assurances" line. The developer agrees to sign any additional paperwork later, at your request, to perfect your ownership, for example if an investor's lawyer wants a fresh signature.
6. Contractor-of-contractor coverage. If the agency uses subcontractors, the clause must ensure those people have assigned their rights up the chain to the agency, so the agency can pass full ownership to you. A gap here is where most hidden IP problems live.

When should ownership transfer to you?

Timing is a negotiation, and it is where leverage lives. Three common structures, from worst to best for you:

• Everything on final payment only. The developer holds all rights until the very last invoice is paid. This is the industry norm and it is workable, but it means that if a dispute erupts in week three, they hold the code and you hold nothing.
• Per milestone. Ownership of each deliverable transfers when you pay for that milestone. You are never far behind on what you own, which reduces the "hostage" risk mid-project. This pairs naturally with a milestone-based payment schedule.
• Escrow of the source. For larger builds, the source code is placed with a neutral third party and released to you under defined conditions. This is overkill for most MVPs but worth knowing exists.

For a typical fixed-price MVP, per-milestone transfer with a final catch-all assignment on completion is the sweet spot. You stay protected throughout, and the developer still has a clean incentive to finish. Either way, insist that final payment triggers a complete, unconditional assignment of everything, plus delivery of the actual source code repository, not just a running copy of the app.

The open-source and third-party nuance

Almost every modern app is built partly from open-source libraries and paid third-party services. Your developer cannot assign you ownership of those, because they never owned them either. That is normal and nothing to fear. What you want instead is a clause confirming two things: first, that all custom code written specifically for you is assigned to you in full; and second, that any third-party components are under standard permissive licenses (or paid subscriptions in your name) that let you use, modify, and sell your product without surprise fees or restrictions. A responsible team will list the major dependencies so there are no surprises later. If a build leans on some proprietary component only the developer can license, that is a dependency you should know about before you sign, because it quietly ties you to them.

Red flags to watch for

• The contract talks about "delivering the software" but never uses the words "assign" or "ownership."
• You are granted a "license to use" the product rather than ownership of the code.
• Ownership is contingent on an ongoing retainer or maintenance contract.
• The developer wants to retain rights to "reusable components" that turn out to be central to your product.
• No mention of subcontractors, even though the team clearly uses them.
• You get a compiled or hosted app but no access to the source repository.

If you see these, do not panic and do not accuse; just ask for the assignment language to be added. A reputable developer will say yes without friction, because they never intended to keep your code. A developer who resists is telling you something important.

Where this fits in hiring well

IP assignment is one piece of vetting a builder properly. It sits alongside the questions you ask before you sign and the way you structure payment. If you are still choosing who to work with, our list of questions to ask before hiring an MVP developer and our guide to how to hire an MVP development company both put ownership on the checklist where it belongs. And before you agree to any number, the free MVP cost calculator gives you a market range so you can tell a fair quote from a padded one.

At SquadPrime we make this simple: our fixed-price MVP builds, which start from $4,000 depending on scope, include a full IP assignment, so you own 100% of the code on delivery. Senior professionals write it, you own it, and there is no license trap to escape later. Clear ownership is not a premium add-on; it is the baseline a serious founder should expect.

FAQ

If I pay a freelancer to build my app, do I own the code?

Not automatically. In the United States and most of the world, the person who writes the code is the default owner of the copyright, even after you pay them, unless a written contract assigns those rights to you. Paying an invoice buys the work; it does not by itself transfer ownership of the intellectual property. You need an explicit IP assignment clause in writing.

What is the difference between a license and an assignment?

An assignment transfers ownership: the rights become yours and the developer keeps nothing. A license only grants permission to use something the developer still owns, and it can carry limits, fees, or an expiry. For your core product code you want a full assignment. A license is fine, and often unavoidable, for third-party or open-source components you did not commission.

When should the IP transfer to me during the project?

The cleanest arrangement is that ownership of each deliverable transfers to you upon payment for that milestone, with a final catch-all assignment of everything on final payment. Avoid contracts where the developer holds all rights until the very last invoice with no interim transfer, because that gives them leverage if a dispute arises mid-build.

Does IP assignment cover open-source and third-party code in my app?

No, and it should not try to. A developer cannot assign you ownership of open-source libraries or third-party services they did not create. A good contract assigns you full ownership of the custom code written for you, and separately confirms that any third-party components are under standard permissive licenses that let you use and sell your product without extra fees.

This article is general information for founders, not legal advice; laws differ by country and change over time, so verify specifics with a qualified attorney before signing. Any terms referenced were current as of September 21, 2026. Spotted something outdated or inaccurate? Email talk@squadprime.com and we'll correct it promptly.

Related: What to put in a development contract · Questions to ask before hiring an MVP developer