Who Owns the Code? IP Clauses Every App Client Must Demand
A plain-language guide to app development IP ownership contract terms — work-for-hire, pre-existing IP, and how to ensure you own your product outright.
You’ve hired a studio, paid the invoices, and launched your app. But do you actually own it? For many founders and business owners, the answer turns out to be “not entirely” — sometimes not at all. Intellectual property (IP) clauses are among the most overlooked parts of any app development IP ownership contract, yet they determine who controls your product, who can resell the code, and whether you can switch developers without starting over. This guide explains what to look for, what to demand, and what red flags to avoid — in plain language, no law degree required.
Why IP Ownership Is a Business Problem, Not Just a Legal One
Ownership of your app’s source code is a business asset question just as much as it is a legal one. Consider what’s at stake:
- Fundraising. Investors and acquirers will inspect IP ownership during due diligence. Unclear ownership can kill a deal.
- Switching vendors. If the studio retains the code, you may be locked in indefinitely.
- Reselling or licensing. You can only monetize what you legally own.
- Enforcement. If a competitor copies your app, you can only sue if you own the copyright.
Most disputes don’t happen because a vendor is dishonest — they happen because contracts were vague or used the wrong legal framework. Getting this right before you sign is far cheaper than resolving it in court.
The Work-for-Hire Clause: Your Most Important Line Item
In many jurisdictions (including the United States), copyright in a creative work — including software — belongs to the author by default, not the person who paid for it. The exception is work-for-hire: a legal doctrine that, when correctly invoked, transfers copyright to the commissioning party automatically.
For work-for-hire to apply, you generally need:
- A written agreement signed before work begins.
- Language that explicitly states the work is “made for hire” and that all IP vests in the client.
- The work must qualify under the applicable statute (requirements vary by country).
What to demand in your contract:
- A clause stating that all code, designs, and deliverables produced under the engagement are works made for hire owned solely by you.
- A fallback assignment clause: “To the extent any deliverable does not qualify as a work made for hire, Contractor hereby irrevocably assigns all rights, title, and interest to Client.”
- The assignment should cover patents, trademarks, trade secrets, and moral rights (where waivable), not just copyright.
The fallback assignment clause matters because work-for-hire rules differ between countries. Studios in the EU, UK, or Central Asia may operate under different defaults. A blanket assignment ensures you’re covered regardless of jurisdiction.
Pre-Existing IP: What the Studio Keeps (and Why That’s Okay)
No studio builds every app entirely from scratch. Before you signed, the team likely had:
- Internal frameworks and boilerplate code
- UI component libraries
- Reusable authentication or payment modules
- Third-party open-source libraries
This is called pre-existing IP (sometimes “background IP”), and studios are entitled to keep it. You wouldn’t expect to own a hammer just because a carpenter used it on your renovation. What you should own is everything specific to your product — your business logic, your data models, your brand assets, your unique features.
A well-drafted contract will include a pre-existing IP carve-out: a schedule or exhibit that lists (or describes categories of) IP the studio retains. This creates a clear boundary. Everything not listed in that carve-out should transfer to you.
What to watch for
- A carve-out that is too broad (e.g., “all tools, frameworks, and methodologies”) can swallow the custom work you paid for.
- Ask the studio to be specific. Generic carve-outs are a warning sign.
- Confirm that you receive a license to use any retained pre-existing IP that is embedded in your deliverables — perpetual, royalty-free, and sublicensable.
Source Code Delivery: Own It on Paper and in Practice
Ownership on paper means nothing if the code lives only in the vendor’s private repository. Your contract should guarantee:
- Source code escrow or delivery at defined milestones and at project completion.
- Access to the version control repository (GitHub, GitLab, etc.) with owner-level permissions, not read-only.
- Handoff of all credentials: App Store Connect, signing certificates, API keys, and third-party service accounts.
- Documentation sufficient to allow another team to continue development.
We include repository transfer and credential handoff as a standard step in every engagement — clients who browse our past work will see that full ownership and continuity are built into how we deliver, not added as an afterthought.
Confidentiality and Non-Compete Provisions
IP ownership goes beyond the code itself. Make sure your contract also covers:
- Confidentiality (NDA): The studio should not disclose your business logic, roadmap, or data to third parties.
- Non-solicitation: Prevents the studio from hiring your key staff or poaching your customers.
- Portfolio rights: Studios often want to list your app in their portfolio. This is reasonable, but define the scope — screenshots and a one-line description are fine; publishing source code is not.
A Contract Checklist Before You Sign
Use this checklist when reviewing any app development agreement:
| Clause | What to Look For | Red Flag |
|---|---|---|
| Work-for-hire | Explicit statement; fallback assignment | No IP language at all |
| Pre-existing IP carve-out | Specific list or narrow categories | Overly broad carve-outs |
| Assignment scope | Code, designs, patents, trademarks | Copyright only |
| Source code delivery | Milestones + final handoff | ”Available on request” |
| Repository access | Owner-level permissions | Read-only or no access |
| Credential handoff | All accounts and certificates | Not mentioned |
| License to retained IP | Perpetual, royalty-free, sublicensable | Revocable or time-limited |
| Confidentiality | Mutual NDA, defined term | One-sided or absent |
| Governing law | Jurisdiction you can enforce | Obscure or vendor-friendly only |
What to Do If You Already Have a Contract Without These Clauses
If work is underway or complete and your contract is silent on IP, you still have options:
- Negotiate an amendment. Most reputable studios will sign an IP assignment addendum if asked professionally.
- Request a formal assignment deed. A short document that transfers all rights can be executed after the fact, though this is harder if the relationship has soured.
- Consult a technology attorney. Particularly if the app is high-value or investor-facing, a one-hour legal consultation is a wise investment.
Common Questions
Q: Does paying the invoice automatically transfer ownership to me? No. Payment transfers money; ownership transfers only through a written IP assignment or valid work-for-hire clause. Without the right contract language, the developer likely retains copyright by default.
Q: Can I use open-source libraries in my app and still own the product? Yes, as long as the open-source licenses are compatible with commercial use (MIT, Apache 2.0, and BSD are generally safe). GPL and similar “copyleft” licenses can restrict distribution. Ask your studio to provide a dependency list with license types.
Q: What if the studio is based in another country? Governing law and jurisdiction clauses become critical. Choose a jurisdiction you can realistically enforce in, and ensure the assignment language is broad enough to cover international rights. If you’re unsure, a brief review by a local IP attorney is worthwhile.
Know What You’re Buying Before You Build
The best time to address IP is before a line of code is written. A transparent studio will welcome these questions — because they reflect a client who is serious about their product. Vague or evasive answers to IP questions are one of the clearest signals to walk away.
At Fera Tech, our contracts are structured so that clients own their product outright from day one. You get the source code, the accounts, the certificates, and the documentation. We keep our reusable tooling; you keep everything we built for you. Learn more about how we work at /#services or see examples of what we’ve shipped at /#work.
If you’re starting a new app project or reviewing a contract with an existing vendor, we’re happy to talk through what a clean engagement looks like. Reach out to us — no obligation, just a straight conversation.
Building something like this?
Fera Tech ships iOS & full-stack apps end-to-end. Tell us about your project.
Start a project