When you outsource app development, the question founders ask most often is simple: will I actually own what I am paying for? The honest answer is that ownership depends on two things working together. The contract has to assign the rights clearly, and the operational setup, meaning who holds the repositories, cloud accounts and store listings, has to match what the contract says.
This article covers both sides as we handle them in offshore mobile app development engagements: the clauses to look for, the accounts you should control from day one, how to manage access and offboarding, and the open-source obligations that come with almost every app. It is practical guidance from a delivery perspective, not legal advice. Have a qualified lawyer in your jurisdiction review any agreement before you sign.
What counts as IP in an app project
Intellectual property in a mobile project is broader than the source code. It includes UI designs and design files, app icons and brand assets, written copy, database schemas, API specifications, documentation, test suites, build scripts and infrastructure configuration. Your data, including user data and any trained model weights, also needs clear treatment.
Write these categories into the statement of work. A contract that only says "the software" leaves room to argue about design files, automation scripts or the backend.
Contract clauses that matter
Copyright and ownership rules differ by country, and the default position for commissioned work is not always that the client owns it. That is why an explicit assignment clause matters, especially across borders.
| Clause | What it should do | Watch out for |
|---|---|---|
| IP assignment | Assign all rights in deliverables to you, typically on creation or on payment | Assignment only on final payment with no interim license; vague deliverable definitions |
| Pre-existing IP | List vendor-owned tools or components and grant you a perpetual license to use them in the app | Unlisted "internal frameworks" that the app depends on |
| Confidentiality / NDA | Protect your business information, data and code during and after the engagement | Short survival periods; carve-outs that are too broad |
| Personnel agreements | Confirm the vendor's staff and subcontractors have assigned rights to the vendor so the vendor can assign them to you | Freelancers or subcontractors with no written agreement |
| Data protection | Define how personal data is processed, stored and deleted | No data processing terms where privacy laws such as GDPR apply |
| Termination and handover | Require delivery of code, credentials, documentation and assets on exit | Handover tied to disputed invoices with no partial release |
| Governing law | State which jurisdiction's law applies and how disputes are resolved | A forum that is impractical for you to use |
Engagement structure also affects how these clauses are written. A fixed-price project, time and materials and a dedicated team each handle deliverables and acceptance differently; our explainer on choosing an engagement model covers those differences, and the broader guide to outsourcing mobile development walks through contracting steps.
Own the accounts, not just the paperwork
A signed assignment clause is much easier to enforce when you already hold everything. The simplest rule: create every account under your organization, then invite the vendor with a role. Do it at kickoff, not at launch.
- Source control: a GitHub, GitLab or Bitbucket organization owned by you, with the vendor's engineers added as members.
- Apple Developer Program: enrolled as your organization, with vendor staff added through App Store Connect roles. Transferring an app between accounts later is possible but adds work and delay.
- Google Play Console: your developer account, with vendor users granted specific permissions. Keep control of app signing keys through Play App Signing.
- Cloud and backend: AWS, Google Cloud, Azure or Firebase projects billed to you, with the vendor using scoped roles.
- Third-party services: analytics, crash reporting, payments, maps and email providers registered to your company email domain.
- Domains and DNS: registered to you, since deep links, email and API endpoints depend on them.
Access control during the engagement
Least privilege is as much about reducing mistakes as about preventing theft. Give each person only the access their role requires, and review it on a schedule.
- Use named accounts for every engineer; never share logins.
- Enforce multi-factor authentication across source control, cloud and store accounts.
- Protect the main branch and require reviews before merging.
- Keep production secrets in a secrets manager; developers should not need production database credentials.
- Separate development, staging and production environments, and limit who can deploy to production.
- Use test or anonymized data in non-production environments, particularly for health and financial apps.
Offboarding people and vendors
Engineers rotate, and engagements end. Offboarding should be a checklist, not a scramble.
- 1
Remove access the same day
Revoke source control, cloud, store, CI and third-party tool access when someone leaves the project.
- 2
Rotate shared secrets
Rotate any API keys, service account credentials or signing material the person could have seen.
- 3
Collect the handover
Confirm documentation, design files, architecture notes and open issues are in your systems, not personal drives.
- 4
Verify you can build
Have someone else produce a clean build from your repo and pipeline, using your accounts only.
- 5
Confirm in writing
On vendor exit, get written confirmation that copies of your confidential data have been returned or deleted as the contract requires.
Source code escrow: when it helps
Source code escrow places a copy of code with a neutral third party, released to you if agreed events occur, such as the vendor going out of business. It is most valuable when the vendor owns the code and licenses it to you, for example a white-label platform or a hosted product. If you own the repository and receive commits continuously, you already hold the code, and escrow adds little. In that case, spend the effort on making sure builds are reproducible and documentation is current.
Open-source license compliance
Almost every app depends on open-source packages. Permissive licenses such as MIT, BSD and Apache 2.0 generally allow commercial use with attribution. Copyleft licenses such as the GPL family can impose obligations that conflict with app store distribution or with keeping your code private. These are complex areas where legal advice is worth having.
- Ask your vendor to maintain a software bill of materials (SBOM) listing each dependency and its license.
- Add automated license scanning to CI and agree which licenses need approval.
- Include required attribution notices in the app, usually on an open-source licenses screen.
- Make sure the vendor discloses any code reused from previous projects.
If you are weighing a vendor on these points, our dedicated development team model works inside your accounts by default. Questions about how we set this up can go through our contact page.
Frequently asked questions
Is an NDA enough to protect my app idea?
An NDA protects confidential information, but it does not transfer ownership of the work. You also need an IP assignment clause covering the deliverables, and an operational setup where you control the code and accounts.
Should the app be published under my developer account or the vendor's?
Yours. Publishing under your own Apple and Google developer accounts keeps the listing, reviews, ratings and revenue under your control. Vendors can be given team access to manage builds and releases.
Do I need source code escrow if I own the repository?
Usually not. Escrow mainly protects you when the vendor holds the code. If commits go into a repository you own, focus on reproducible builds and clear documentation instead.
Does working offshore change how IP law applies?
It can. Ownership defaults, enforcement and dispute processes vary by country, which is why explicit assignment clauses and a clear governing-law provision matter. This is not legal advice; consult a lawyer familiar with both jurisdictions.
This article is general guidance based on common delivery practice. It is not legal, tax or financial advice; platform rules and regulations change, so confirm current requirements with the relevant provider or adviser.