Buyers often assume that paying for software means owning it. In many countries the default can be the opposite: whoever wrote the code may hold the copyright until a written agreement transfers it. The rules differ by country, and this guide is not legal advice, so have a lawyer read the final contract. If your developer is in India, ask your lawyer about section 19 of the Copyright Act 1957, where an assignment that does not state a period is treated as five years, and one that does not state a territory as India only. Have the contract say “worldwide” and give the period. These are the things to get right.
What the contract should say
- Who owns the code written for you, and from when. Common versions are on creation, or on payment for each milestone. Transfer only on final payment can leave you with nothing if a project stops at milestone three.
- Who else writes code. A company can only transfer what it owns. It should confirm that staff and any subcontractors have passed their rights to it, and tell you if it uses subcontractors or AI coding tools.
- What is included. Source code, designs, database structure, build scripts, documentation and test assets. If it is not listed, it can become an argument later.
- What is not included. A company may reuse its own general libraries or starter code. That is normal, but you should get a licence to keep using them, in writing, for as long as you use the product.
- Third-party licences. Most apps rely on open-source libraries and paid services. Ask for a list, and look for copyleft licences such as GPL or AGPL, which can require you to share your own code, and for any paid component that needs its own licence.
- Confidentiality, in both directions. Your idea and data stay private. Agree whether your project may be mentioned publicly, even anonymously.
- What happens when the work ends. Notice period, handover of code and access, and how long the team will answer questions.
Control matters as much as contract wording
A signed clause does not help if you cannot reach your own code. From the first week, your company should hold:
- The code repository, with the team invited as collaborators.
- App Store and Google Play accounts, in your company’s name.
- App signing. On Android, use Play App Signing under your own account, so a lost upload key can be reset. On iOS, your App Store Connect account is what matters, since certificates can be reissued.
- Servers, databases, domains and DNS, on accounts you control and pay for where possible.
- Third-party services such as payments, maps, email and AI providers.
If a team asks to hold these for convenience, ask why. Sometimes there is a reason for a short period at the start. It should not be permanent.
How to check it without being technical
- Ask for read access to the repository on day one, and look at it once a week. You do not need to read the code. You only need to see that work is arriving regularly, though regular commits show activity, not quality.
- Ask someone other than the developer to build the app from the repository once. If only one person’s laptop can build it, you do not fully have it.
- At every milestone, tick a short list: code in the repository, build instructions updated, credentials recorded.
Developers working inside your team
If you hire dedicated developers from a company, check who employs them and how their work transfers to you. The contract should cover that, and the developers should work in your repositories and tools from the start.
How we handle this
We do not have one standard clause; we agree code and intellectual property per project and put it in the project agreement before work starts. We recommend that accounts are in your company’s name. See How we work for what is handed over, and tell us what you need in writing.