Who Owns the Code? IP Ownership in App Development Contracts

You paid $80,000 for an agency to build your app. You own the app. Right?

Maybe. It depends on what the contract says, what jurisdiction governs it, and whether the contract distinguishes between the code written specifically for your project and the reusable tools, libraries, and frameworks the agency brought to the table.

IP ownership is the sleeper issue in app development contracts. Founders focus on price, timeline, and features during the negotiation and skim the IP clauses because they seem like boilerplate. Then the project ends, the relationship with the agency sours, and the founder discovers that the agency owns the underlying framework their app is built on, or that they have a non exclusive license rather than full ownership, or that "ownership upon payment" has a specific meaning that does not match what they assumed.

Below is what IP ownership in app development actually means, what the contracts should say, where the common pitfalls hide, and how to protect yourself regardless of which agency or freelancer you hire.

The Default Rule: Why You Might Not Own What You Paid For

In most jurisdictions, including the United States, the default rule for intellectual property created by an independent contractor is that the contractor owns it. This is the opposite of the default rule for employees, where the employer owns work created within the scope of employment.

When you hire an agency or freelancer to build an app, they are independent contractors, not employees. Unless the contract specifically assigns the IP to you, the agency owns the code they wrote, the designs they created, and the documentation they produced. You have an implied license to use the deliverables, but you do not own them.

This default catches founders off guard because the intuitive expectation ("I paid for it, I own it") does not match the legal reality. The fix is direct: the contract must include an explicit assignment of intellectual property. But the details of that assignment matter.

What "IP Assignment" Covers

A well drafted IP assignment clause transfers ownership of several categories of intellectual property:

Copyright in the source code. The code written by the development team is a copyrightable work. The assignment transfers the copyright from the agency (who created it) to the client (who paid for it). This gives the client the exclusive right to copy, modify, distribute, and create derivative works from the code.

Copyright in the visual design. The UI designs, icons, illustrations, and visual assets created for the project are copyrightable works. The assignment transfers ownership of these assets. This is distinct from the code assignment because the designs might be created by a different team member or a subcontracted designer.

Copyright in documentation. Technical documentation, user guides, API documentation, and architecture documents created for the project are copyrightable works.

Trade secrets embedded in the code. If the project involves proprietary algorithms, business logic, or data processing methods that give the client a competitive advantage, the assignment should explicitly cover these trade secrets.

Moral rights waiver (where applicable). In some jurisdictions, the creator of a copyrightable work retains moral rights (the right to be attributed as the author, the right to object to modifications) even after transferring the copyright. A moral rights waiver ensures the client can modify the code without the original developers’ consent.

What IP Assignment Typically Does Not Cover

Reasonable IP assignment clauses exclude certain categories of intellectual property because full transfer would be either impractical or unfair:

Pre existing IP. The agency brings tools, libraries, frameworks, and code snippets that they developed before your project and use across multiple client projects. These are the agency’s pre existing intellectual property, and you should not expect (or want) exclusive ownership of them. What you should get is a perpetual, irrevocable, royalty free license to use the pre existing IP as embedded in your project.

The distinction between "code written for your project" (which you own) and "code the agency brought to your project" (which you license) is the most important structural element of the IP clause. A contract that does not make this distinction creates ambiguity that could become a dispute.

Open source components. Modern software is built on open source libraries. A typical mobile app uses dozens of open source packages for networking, UI components, state management, encryption, and other functions. These packages are governed by their own licenses (MIT, Apache 2.0, GPL, BSD). Neither you nor the agency owns these packages. Both of you use them under the terms of their licenses.

The contract should acknowledge the use of open source components and specify that the agency will not introduce open source components with licenses that restrict your ability to use, modify, or distribute the application commercially. The GPL (GNU General Public License) is the most common restrictive license: software that incorporates GPL licensed code must itself be released under the GPL, which is incompatible with most proprietary software business models.

Third party services and APIs. Your app likely uses third party services (AWS, Firebase, Stripe, Plaid) under their own terms of service. You do not own these services, and the IP assignment does not affect your relationship with them. But the contract should specify who owns the accounts and credentials for these services, because access to these accounts is necessary to operate and maintain the app.

‍

A glass vault door half open revealing glowing red code blocks

‍

Contract Clauses to Look For

A well drafted app development contract should include these IP related provisions:

Work for hire declaration or IP assignment.

"Work for hire" is a legal term under US copyright law that means the employer (or commissioning party, for certain categories of work) owns the copyright from the moment of creation. However, software does not clearly fit the statutory categories of work that qualify for work for hire treatment when created by independent contractors. Relying solely on a work for hire clause is risky.

The safer approach: include both a work for hire clause (to the extent applicable) and a separate IP assignment clause (transferring any IP not covered by the work for hire clause). This belt and suspenders approach ensures coverage regardless of how a court interprets the work for hire provision.

Pre existing IP schedule.

The contract should include a schedule (attachment or exhibit) listing the agency’s pre existing IP that will be used in the project, along with the license terms under which the client can use it. If the agency says "we use our proprietary framework for all projects," that framework should be listed, and the license should be perpetual, irrevocable, and royalty free.

Open source disclosure.

The agency should disclose the open source components they plan to use and confirm that none carry licenses that restrict the client’s commercial use. Some contracts require the agency to provide a software bill of materials (SBOM) that lists every open source dependency at project completion.

Source code escrow or immediate access.

The client should have access to the source code repository (GitHub, GitLab, Bitbucket) throughout the project, not just at completion. If the agency uses a private repository, the client should be added as a collaborator from day one. This protects against the scenario where the agency goes out of business, becomes unresponsive, or refuses to hand over the code.

Some contracts include a source code escrow provision, where the code is held by a third party and released to the client if certain trigger events occur (agency bankruptcy, failure to maintain the software, contract termination). Escrow is more common in enterprise contracts and less common in startup engagements, but it is worth considering for mission critical applications.

Assignment upon payment.

The standard provision: IP transfers to the client upon receipt of full payment for each milestone or for the project as a whole. This protects the agency (they retain IP until paid) and the client (they receive IP upon payment). The trigger ("upon payment") should be specific: does the IP transfer upon payment of each milestone or only upon final payment of the entire project?

The safest arrangement for the client: IP in completed milestones transfers upon payment of that milestone, not upon payment of the final milestone. This ensures that if the project terminates mid way, the client owns the work that has been completed and paid for.

Post termination provisions.

What happens to IP if the project is terminated before completion? The contract should specify that the client owns all IP in work completed and paid for as of the termination date, and that the agency will deliver all code, designs, documentation, and credentials for work completed to date.

Common IP Pitfalls in Agency Contracts

The licensing trap. Some contracts grant the client a "license" to use the deliverables rather than assigning ownership. A license can be exclusive or non exclusive, limited or perpetual, revocable or irrevocable. A non exclusive, revocable license means the agency can license the same code to your competitor and can terminate your right to use it. Read the IP clause carefully to confirm it is an assignment (transfer of ownership), not merely a license (permission to use).

The portfolio rights clause. Many agency contracts include a clause granting the agency the right to include the project in their portfolio. This is reasonable. But some clauses go further, granting the agency the right to reuse the code, the design, or the architecture in future projects. If the agency can reuse your custom built features in a competitor’s project, the IP assignment is less valuable than it appears. Portfolio rights should be limited to displaying screenshots, describing the project at a high level, and listing the client as a reference, not to reusing the deliverables.

The subcontractor gap. If the agency uses subcontractors (freelancers, offshore developers), the IP assignment between you and the agency does not automatically cover the subcontractors’ work. The agency must have its own IP assignment agreements with its subcontractors. Ask the agency to confirm that all subcontractors have assigned their IP to the agency and that the agency can therefore assign it to you.

The "reasonable efforts" clause. Some contracts require the agency to use "reasonable efforts" to assign IP rather than making an unconditional assignment. "Reasonable efforts" introduces ambiguity about what happens if the assignment fails (e.g., a subcontractor refuses to sign the assignment). Replace "reasonable efforts" with unconditional assignment language and require the agency to obtain subcontractor assignments before using subcontractors on your project.

Missing credentials and account access. IP ownership without access to the code and infrastructure is ownership on paper only. The contract should require the agency to transfer or grant access to: the source code repository, cloud hosting accounts (AWS, GCP, Azure), App Store and Play Store developer accounts (or publish the app under the client’s accounts from the start), third party service accounts (Stripe, Firebase, analytics platforms), domain registrations, and SSL certificates.

Under Bolder Apps contracts, the client owns all custom code outright upon each milestone payment. Pre existing IP (internal tools and frameworks the agency brings to the project) is disclosed upfront and licensed separately on a perpetual, irrevocable basis. The client has access to the source code repository from day one rather than at project completion, which eliminates the code access risk that can create leverage in disputes. For founders evaluating any agency’s contract, the key question is not whether the agency says you will own the code but whether the contract language creates an unambiguous, unconditional assignment with complete access.

IP Ownership and Fundraising

Investors and acquirers examine IP ownership during due diligence. Issues that create friction:

Unclear IP chain of title. If the agency contract does not clearly assign IP, or if the agency used subcontractors without proper assignments, the investor’s legal team will flag it. Cleaning up IP chain of title retroactively requires cooperation from the original agency and potentially from their subcontractors, which may not be available.

GPL or restrictive open source components. The use of GPL licensed code in a proprietary application is a due diligence concern. Investors may require a clean room rewrite of the GPL components, which adds cost and timeline to the fundraising process.

Agency retained framework rights. If the agency retains rights to the underlying framework and the licensing language is ambiguous, investors may view it as a risk to the company’s ability to operate independently of the agency.

No SBOM or dependency documentation. Investors increasingly request a software bill of materials as part of technical due diligence. If the development team did not maintain dependency documentation, producing it after the fact is time consuming and incomplete.

The time to address these issues is during the development contract negotiation, not during the Series A due diligence process. A clean IP chain of title from the first line of code saves weeks of legal work and tens of thousands of dollars in legal fees during fundraising.

‍

Ribbed glass puzzle pieces fitting together with a red seam

‍

What to Do If You Already Have an IP Problem

If you are reading this after the contract was signed and you are uncertain about your IP position:

Review the contract. Look for: the IP assignment or license clause, the definition of "deliverables" or "work product," the payment trigger for IP transfer, and any provisions about pre existing IP, subcontractors, or open source components. If the contract is ambiguous, have a lawyer read it.

Request a representation letter. Ask the agency to provide a letter confirming that they have assigned all IP in the deliverables to you, that all subcontractors have assigned their IP to the agency, and that no restrictive open source licenses have been used. Most reputable agencies will provide this. An agency that refuses is raising a flag.

Audit the open source components. Run a license scan on the codebase using tools like FOSSA, Snyk, or license checker (for Node.js projects). This identifies every open source dependency and its license type. Flag any GPL or AGPL components for legal review.

Secure all accounts and credentials. Confirm that you have ownership or administrative access to the source code repository, the cloud hosting accounts, the App Store and Play Store accounts, and all third party service accounts. If any of these are registered under the agency’s accounts, request transfer immediately.

Document the IP chain. Create a document that maps every piece of the application to its IP status: client owned (custom code assigned by contract), agency licensed (pre existing IP with a perpetual license), open source (with specific license identified), and third party (used under vendor terms of service). This document becomes the basis for any future due diligence.

IP Ownership With Freelancers

Freelancer contracts deserve the same IP attention as agency contracts, with additional considerations:

Freelancers are more likely to reuse code across clients because they do not have the revenue to build and maintain a proprietary framework. The code they write for you may include fragments from previous projects, which creates a potential IP conflict with those previous clients.

Freelancer contracts are more likely to be informal (a brief scope of work or a verbal agreement) without explicit IP provisions. The default rule (contractor retains IP) applies even more strongly when there is no written contract.

Freelancers working on platforms (Upwork, Toptal, Freelancer.com) may be covered by the platform’s standard terms, which typically include IP assignment to the client. Check the platform’s terms rather than assuming.

For any freelancer engagement: use a written contract with explicit IP assignment, require the freelancer to represent that they have the right to assign the work (i.e., it does not include IP belonging to a previous client), and maintain access to the code repository from the first commit.

The Practical Checklist

Before signing any app development contract:

Confirm the contract includes an unconditional IP assignment (not just a license) for all custom work
Confirm the assignment transfers upon payment of each milestone, not only upon final payment
Identify any pre existing IP the agency will use and confirm the license terms are perpetual, irrevocable, and royalty free
Confirm the agency has IP assignment agreements with all subcontractors
Confirm you will have source code repository access from day one
Confirm the agency will not use open source components with restrictive licenses (GPL, AGPL) without your approval
Confirm the portfolio rights clause is limited to display and description, not to code reuse
Confirm the contract specifies transfer of all accounts and credentials upon project completion
Confirm the post termination provisions entitle you to all completed work if the project ends early
Have a lawyer review the IP provisions if the project cost exceeds $50,000 or the IP is strategically important

Open Source License Types and What Each Means for Your App

Not all open source licenses carry the same obligations. Understanding the major license types prevents compliance surprises during investor due diligence:

MIT License. The most permissive common license. You can use, modify, and distribute MIT licensed code in commercial products with no obligation beyond including the original copyright notice. Almost every mobile app uses MIT licensed packages, and the MIT license creates no risk for proprietary software.

Apache 2.0 License. Similar to MIT with an explicit patent grant: the contributors grant you a license to any patents that cover their contribution. The Apache 2.0 license is common in Google originated projects (Angular, many Android libraries) and creates no risk for proprietary software.

BSD Licenses (2 clause and 3 clause). Similar to MIT in practice. The 3 clause version adds a restriction against using the original author’s name for endorsement. No risk for proprietary software.

LGPL (Lesser General Public License). Code under LGPL can be used in proprietary software if it is linked dynamically (not compiled into the application). Static linking triggers the GPL’s copyleft requirement, which would require your entire application to be released under GPL. Most mobile app frameworks use dynamic linking, but the distinction matters and should be verified.

GPL (General Public License). The copyleft license. If your application incorporates GPL licensed code, the entire application must be released under GPL, which means making the source code available to anyone who receives the application. This is incompatible with proprietary software business models. GPL licensed components in a mobile app are a due diligence red flag that investors and acquirers will flag.

AGPL (Affero General Public License). Like GPL but extends the copyleft requirement to software accessed over a network (SaaS products). Even more restrictive than GPL and even more incompatible with commercial software.

The practical rule: MIT, Apache 2.0, and BSD licenses are safe for commercial mobile apps. LGPL requires verification of linking type. GPL and AGPL are incompatible with proprietary apps and must be avoided or replaced with alternatively licensed components.