Who Actually Owns Your App? Source Code, IP and the Handover Test

Hinney Lo (CEO) 4 min read
Who Actually Owns Your App? Source Code, IP and the Handover Test

Paying for an app does not automatically make you the owner of its source code. In most jurisdictions the author of the code holds copyright by default, and that only transfers to you if the contract assigns it in writing. Plenty of otherwise sensible agreements grant you a licence to use the finished product without ever transferring the underlying rights, and the difference is invisible until the day you want to change developers.

This is not usually a story about bad actors. It is a story about contracts written to describe a deliverable rather than an asset, and about businesses who assumed that paying an invoice settled the question. It does not.

The three things people mean by "owning the app"

The word ownership gets used for three separate things, and a contract can give you one without the others:

  • The intellectual property. The copyright in the source code, and the right to modify it, license it and build on it. This is the one that requires explicit written assignment.
  • The artefacts. The repository, the commit history, the build pipeline, the infrastructure configuration, the design source files, the documentation. You can own the IP in the abstract and still be unable to exercise it if you do not hold these.
  • The accounts. The Apple Developer and Google Play accounts, the cloud account, the domain, the analytics, the certificates and signing keys. Apps have been effectively hostage to a signing key held in someone else's account more often than anyone likes to admit.

All three need to be addressed. An IP assignment clause with no obligation to hand over the repository is a right you cannot use.

What to look for in the contract

You are looking for a clause that assigns all intellectual property in the deliverables to you on payment, and that survives termination. Beyond that, four things are worth checking specifically:

  • What is carved out. Most agencies retain rights in their own pre-existing tools, libraries and frameworks, and that is entirely normal - you should be getting a perpetual licence to use them within your product, not ownership of an agency's internal toolkit. What matters is that the carve-out is specific. A broad carve-out for "methodologies and know-how" is fine; one that captures anything reusable is not.
  • Third-party and open-source components. Nobody assigns you rights they do not hold. Your product will contain open-source dependencies under their own licences, and you want a list rather than a surprise.
  • When the assignment takes effect. On payment of each invoice is much safer for you than on completion of the project, because it means a dispute mid-project does not leave you with nothing.
  • The further-assurances obligation. A clause requiring the developer to sign whatever additional paperwork is needed to perfect the transfer. Without it, an assignment can be theoretically valid and practically difficult.

This is a legal question and it deserves a lawyer rather than a development partner. We are describing what tends to matter, not giving advice on your agreement.

The handover test - the part that actually proves it

Contract language settles the right. It does not tell you whether you can exercise it. There is a simple test that does, and it can be run at any point in a live engagement without drama:

Ask for a clean-room build. Request everything a new developer would need to check out the code, build it, and deploy it to a test environment - and then have someone who is not on the project try it. Not a code export. A working build from a clean machine.

What this surfaces is everything the contract does not: undocumented environment variables, credentials living on one developer's laptop, a build step that only works on a particular machine, infrastructure configured by hand and never captured anywhere. None of those are ownership problems in law. All of them are ownership problems in practice.

If a partner is reluctant, that is information. If they are willing but it takes three weeks, that is also information - it is roughly what your emergency handover will cost you when you need it under pressure.

What a good handover looks like

We rescued the Train With Cass fitness app through a seamless handover from the previous developer, taking the crash rate down 90 percent, achieving 99 percent uptime and cutting maintenance costs 50 percent. The handover being seamless was not luck - it was possible because the artefacts existed and could be transferred.

The contrast is worth stating plainly, because we see both. We have rescued 15+ platforms in the past 3 years, and the projects that take longest are not the ones with the worst code. They are the ones where nobody can produce a working build, so the first several weeks are archaeology rather than engineering.

Every PixelForce product is built by a 100 percent in-house team, our own employees, the same people from first call to launch, and work is never subcontracted. That matters for this question specifically - a chain of subcontractors is a chain of separate copyright holders, and an assignment is only as good as the weakest link in it.

If you are mid-project and unsure

You do not need to start a dispute to find out where you stand. Read the IP clause, list the three categories above, and ask for a clean-room build. Most partners will handle that as a normal request, because it is one. The ones who do not have told you something you needed to know either way.

If the answer turns out to be uncomfortable and you need a path forward, that is work we do regularly - see app rescue and modernisation, or talk to us about what a transition would involve.

Frequently asked questions

Not automatically. In most jurisdictions the author of the code holds copyright unless it is assigned in writing, and payment for development does not by itself transfer it. Many agreements grant a licence to use the finished product rather than assigning the underlying rights. The only reliable answer is in the contract, and if the contract is silent the default usually does not favour the client.

Yes, and it is normal. Agencies build internal libraries, tooling and frameworks across many projects, and you should expect a perpetual licence to use those inside your product rather than ownership of them. What matters is that the carve-out is specific and listed. A narrow carve-out for named tools is fine. A broad one covering anything reusable can hollow out the assignment entirely.

The repository with full commit history, the build and deployment pipeline, infrastructure configuration, design source files, documentation, and administrative ownership of every account - developer accounts, cloud, domains, analytics, and signing certificates and keys. Ask for it as a working handover rather than a file transfer, and confirm someone outside the original team can build and deploy from it.

Ask for a clean-room build as a routine risk exercise rather than an accusation - most partners treat it as normal, because it is. Frame it as business continuity: you want to know that if the team were unavailable, the product could still be maintained. A partner who is comfortable with their handover position will not object, and one who cannot produce a build has given you information you needed regardless of intent.

It can. Each separate party writing code is a separate copyright holder, so an assignment from your agency is only effective if the agency itself holds valid assignments from everyone who contributed. That chain is rarely visible to the client. It is one practical reason to ask who is actually writing the code, and to prefer an arrangement where the answer is one accountable party.

Keep reading