The $200,000 Question Nobody Asked
We've watched a founder lose access to their entire codebase because they never signed an IP assignment agreement with their developer. The app was generating $40K/month in revenue. The developer wanted a bigger cut. Without a clear ownership clause, the founder had almost no legal ground to stand on.
This isn't rare. After 14+ years of building apps for founders and startups, we've seen IP disputes derail launches, kill funding rounds, and destroy partnerships. The frustrating part is that every one of these situations was preventable with the right agreements in place before a single line of code was written.
Work-for-Hire vs. IP Assignment: Know the Difference
These two terms get thrown around interchangeably, but they're legally distinct, and the distinction matters.
Work-for-Hire
Under U.S. copyright law, a "work made for hire" means the hiring party automatically owns the copyright. But here's the catch most founders miss: work-for-hire only applies automatically to employees, not independent contractors, unless the work falls into one of nine narrow statutory categories (and custom software usually doesn't).
If your developer is a contractor or an agency, a work-for-hire clause alone may not actually transfer ownership to you. Courts have ruled on this repeatedly, and the results aren't founder-friendly when the paperwork is sloppy.
IP Assignment
An IP assignment clause explicitly transfers all intellectual property rights from the creator to you. This is what you actually need when working with contractors, freelancers, or development agencies. A properly drafted IP assignment covers:
- Copyright in the source code, design files, and documentation
- Patent rights for any novel processes or methods built into the app
- Trade secrets including algorithms, data models, and proprietary logic
- Moral rights waivers where applicable
The safest approach is to include both a work-for-hire clause and an IP assignment clause. If the work-for-hire argument fails, the assignment catches it.
What Should Be in Your Developer Agreement
Whether you're hiring a freelancer, a dev shop, or building an internal team, your agreement needs these provisions at minimum:
1. Clear IP Ownership Clause
The agreement should state unambiguously that all code, designs, documentation, and deliverables created during the engagement belong to you (or your company). No exceptions, no shared ownership, no "license back" arrangements unless you specifically want that.
2. Pre-Existing IP Carve-Outs
Good developers bring existing tools, libraries, and frameworks to the table. Your agreement should require them to list any pre-existing IP they plan to use in your project. You don't own their existing tools, but you should get a perpetual, royalty-free license to use them within your product.
This is actually where many disputes start. A developer uses their proprietary component library, doesn't disclose it, and later claims you can't use "their" code. A pre-existing IP schedule prevents this entirely.
3. Non-Compete and Non-Solicitation
You probably can't prevent a developer from building apps for other people. But you can restrict them from building a competing product using the knowledge and architecture they gained from your project. A reasonable non-compete clause (12-18 months, narrowly scoped to your specific market) is standard and enforceable in most jurisdictions.
4. Confidentiality and Trade Secrets
Your NDA should cover not just business information but also technical architecture, algorithms, and data structures. Specifically call out that source code, database schemas, API designs, and deployment configurations are confidential.
5. Source Code Escrow or Access
You should have continuous access to your codebase throughout development, not just at the end. We use shared repositories from day one so founders can see every commit. If your developer won't give you repo access during the build, that's a red flag.
The Open-Source Complication
Almost every modern app uses open-source libraries. Your React Native app might pull in 200+ packages, each with its own license. This doesn't mean you don't own your code, but it does mean you need to understand the licensing implications.
Key license types to watch:
- MIT and Apache 2.0 — Permissive. Use freely in commercial products. Just include the license notice.
- GPL and AGPL — Copyleft. If your code links to GPL libraries, your entire codebase may need to be open-sourced. This has killed acquisition deals.
- BSL (Business Source License) — Increasingly common. Free for small-scale use, paid license required at certain revenue or usage thresholds.
A good development partner will audit your dependency tree and flag any problematic licenses before they become a problem. We do this as part of every project kickoff.
Contractor vs. Employee: The Classification Trap
The IRS and state labor boards don't care what your contract says if the working relationship looks like employment. If you're telling a developer when to work, providing their tools, and they work exclusively for you, they may be classified as an employee regardless of your agreement.
Why does this matter for IP? Because misclassification can invalidate your contractor agreements entirely. If a court determines your "contractor" was actually an employee, different IP rules apply, and you may owe back taxes, benefits, and penalties on top of the IP dispute.
The safest path: work with an established development studio that carries its own insurance, uses its own tools, and manages its own team. The contractor classification is clear, and the IP assignment is clean.
What to Do Before You Sign Anything
Here's our practical checklist for founders entering a development engagement:
- Get an IP assignment clause, not just work-for-hire language
- Require a pre-existing IP schedule listing any tools or code the developer brings to the project
- Demand repository access from day one so you always have your code
- Run an open-source license audit before launch, especially if you plan to raise funding or pursue acquisition
- Use a lawyer who understands software, not your cousin who does real estate closings
- Keep your agreements updated if the scope changes, amend the IP provisions to cover the new work
The cost of a proper IP agreement is typically $2,000-$5,000 in legal fees. The cost of an IP dispute averages $350,000-$750,000 in litigation. The math isn't complicated.
The Bottom Line
Code ownership isn't something you figure out after the app is built. It's something you nail down before the first sprint starts. Every week we talk to founders who assumed they owned their code simply because they paid for it. Payment alone doesn't establish ownership. Signed agreements do.
Get the paperwork right, get repo access, understand what open-source licenses you're inheriting, and work with partners who are transparent about IP from the start. It's the cheapest insurance you'll ever buy for your startup.