NDA and IP protection
App development NDA and IP ownership: how we protect your idea and your code
This page sets out our own terms: what our app development NDA covers, what the IP assignment clause in our contracts says in plain words, where your assets live while we work, and the access register you get when someone leaves the project. It is a summary of our standard position, so you know what you are signing before the first call.
For the general background on why these clauses matter and how to protect an idea with any vendor, read our guide to protecting your app idea and IP when outsourcing.
- NDA signed before discovery
- 100% IP assigned to you
- Code in your repository from day one
What our mutual app development NDA covers
The NDA is signed before discovery, because discovery is when you share the sensitive material: user research, revenue model, data structures, sometimes access to an existing system. You can send your own NDA and we will review it, or use our mutual NDA, which binds both sides in the same way. Here is what ours covers.
| Term | What it says, in plain words |
|---|---|
| Who is bound | Both parties. Mutual means our obligations to you and yours to us are the same. |
| What counts as confidential | What you share with us about the project: pitch decks, user research, data models, business plans, credentials and anything about an existing system. |
| Permitted purpose | We may use your information only to evaluate and deliver your project, nothing else. |
| Who can see it | Only the people working on your project, and they are named. |
| If you don’t go ahead | Return or deletion of your materials, confirmed in writing, can be written into the NDA; agree the wording before you sign. |
| How long it lasts | Stated in the NDA itself; agree the period that suits your project before you sign. |
| When it is signed | Before discovery starts, not bundled into the final contract. |
Ask for the full text of our mutual NDA through the contact page; we reply within one business day. An NDA is a floor, not a fortress: the stronger protection is that your assets never sit in our accounts (see below).
Our IP assignment clause in plain words
Our client contracts include an IP assignment clause. Stripped of legal drafting, it says three things:
- What is assigned: all intellectual property we create for your project, including source code, designs, documentation, test scripts and build configuration, belongs to you.
- When it transfers: agreed in the contract. One option is assignment as each deliverable is created and paid for, rather than at a single handover months later; with code already in your repository, a dispute over a final invoice then cannot cut you off from your own product.
- What sits outside it: open-source packages stay under their own licences, and any pre-existing generic tools of ours (an internal build script, for example) are listed in the statement of work and licensed to you rather than assigned.
If you are US-based you may also want work-for-hire wording; we can add it alongside the assignment. The exact clause wording is in the contract, and your lawyer should read it there rather than rely on this summary.
You own, in full
- Source code and commit history
- UI/UX designs and Figma files
- Backend, APIs and infrastructure config
- Documentation, test plans and release notes
- App Store and Google Play listings
Where your assets live while we work
Clauses matter most when something has gone wrong. These defaults mean you rarely need them: everything is created in your name, and we are invited in.
| Asset | Owned by | Our access |
|---|---|---|
| Source code and commit history | Your GitHub, GitLab or Bitbucket organisation | Collaborators, added by you |
| CI/CD pipelines (GitHub Actions, Codemagic, Fastlane) | Your accounts | Run under your accounts, so you can build and ship without us |
| App Store and Google Play listings | Your Apple Developer Program and Google Play Console accounts | Team roles you grant |
| Cloud resources (Firebase, AWS, Google Cloud, Azure) | Your billing account, your team as owner | Named IAM users |
| Design files | Your Figma workspace | Editors |
| Domains, push certificates and signing keys | Registered to you, keys in your secret manager | Only where a task needs them |
Open-source licences are tracked in a dependency list, and you can ask for a licence report at any point. Why that matters is covered in the IP protection guide.
Read the NDA before your first call
Ask for our mutual NDA and we reply within one business day, with a short call to walk through the IP clause if you want one.
Access register template
We ask for the minimum access each task needs, through named accounts with two-factor authentication, and keep secrets in a password manager or your cloud secret store, never in the repository or a chat thread. Every grant goes into an access register like the one below. When a team member rolls off or the engagement ends, you revoke against it, we confirm, and we rotate any shared key that cannot be tied to one person.
| System | Account or role | Person | Why they need it | Granted | Revoked | Confirmed by |
|---|---|---|---|---|---|---|
| GitHub organisation | Write access to the app repository | Lead developer | Daily commits and pull requests | Sprint 1 | On roll-off | Your admin |
| App Store Connect | Developer role | Release lead | Upload builds to TestFlight | Before first build | On exit | Your account holder |
| Google Play Console | Release manager | Release lead | Internal testing and production rollouts | Before first build | On exit | Your account holder |
| Firebase project | Editor | Backend developer | Auth, database rules, Crashlytics | Sprint 1 | On roll-off | Your admin |
| Staging database | Read-only | QA engineer | Check test data during QA | When QA starts | End of QA | Your admin |
| Shared API key (third-party service) | Not tied to one person | None | Used by the app build | Integration sprint | Rotated on exit | Your admin |
The register is a living document in your workspace, not a file we hand over at the end. Staff augmentation hires follow the same rules; see how to hire mobile app developers on that basis.
Personal data: the DPA and how we keep data out of development
If our team needs access to personal data of EU or UK residents, for example in a staging database or crash logs, we act as your processor, and a data processing agreement (DPA) can be agreed as part of the contract, working within the transfer safeguards your counsel specifies. The app-side obligations, such as lawful basis and consent for SDKs, are covered in our guide to GDPR compliance for mobile apps.
We prefer to keep personal data out of development entirely: anonymised or synthetic test data, production access only for named people with a clear reason, and no personal fields in analytics or crash reports. For health or payment apps (see our HIPAA-compliant app development guide), compliance scope is set in the first sprint and we test against the OWASP MASVS baseline.
What is agreed in the contract, not on this page
Some terms depend on your project, your jurisdiction and your lawyer, so we do not publish a standard answer. Each is written into the services agreement before work starts.
| Term | Where it is set |
|---|---|
| Governing law and dispute forum | Agreed in the contract; your home jurisdiction is one option to discuss |
| Exact IP assignment and work-for-hire wording | Agreed in the contract |
| Pre-existing tools licensed to you | Listed in the statement of work |
| Payment milestones | Agreed in the contract, tied to demonstrable builds |
| Termination and handover obligations | Agreed in the contract |
| NDA duration | Stated in the NDA |
| Data processing terms | In the DPA, when one is needed |
Our app development contract checklist goes clause by clause if you want to review any vendor’s paperwork, including ours. The commercial structure is explained on our app development engagement models page. This page summarises our standard approach. It is not legal advice; have a qualified lawyer in your jurisdiction review any contract before you sign it.
App development NDA and IP: questions about our terms
Will you sign my NDA, or do I have to use yours?
Either. If you send your own NDA, we reply within one business day with any comments and sign once the wording is agreed. If you do not have one, we send our mutual NDA, which protects both sides equally. Either way, it is signed before discovery, so you can share your deck, data model and research without worrying about where it ends up.
When does IP transfer to me?
The timing is agreed in the contract. One option is to assign IP in each deliverable as it is created and paid for, rather than at a single handover at the end. Combined with code living in your repository from day one, a dispute over the final invoice then cannot leave you without access to your own product.
Can you reuse my code for other clients?
No. Code written for your project is yours and is not reused in other client work. We do use general know-how and widely available open-source libraries across projects, as every engineering team does, but your business logic, designs, data and proprietary features stay with you. Any pre-existing vendor tools are listed in the statement of work.
Why should the app be under my own developer account?
Because whoever owns the account controls the app listing, reviews, ratings and update history. Transferring an app between accounts later is possible but adds friction. An Apple Developer Program membership costs $99 a year and a Google Play Console account costs $25 once, so there is little reason to publish under a vendor’s account.
Do you sign a data processing agreement?
A DPA can be agreed as part of the contract. If our team will access personal data of EU or UK residents, for example in logs or a staging database, we act as your processor, and the DPA covers security measures, sub-processors and international transfer safeguards. Where possible we avoid touching real personal data during development by using anonymised or synthetic data.
Is an NDA enough to protect my app idea?
On its own, no. An NDA gives you a legal remedy after a breach, but enforcing one across borders is slow and costly. Stronger protection comes from structure: owning the repository, accounts and cloud resources yourself, limiting access to named people, and having IP assignment in the contract. Treat the NDA as one layer among several.
Send the NDA, then the brief
Send us your NDA or ask for ours. Once it is signed, we will scope your app and send a fixed estimate or a clear range.