Ownership of source code is decided by the written contract, not by who paid or who typed the code. Agree in advance that intellectual property transfers to you on payment, list any third-party or open-source components with their licences, keep repositories and hosting in your own accounts, and require documentation and handover. Have a legal advisor confirm the wording under current Indian law.
- Never assume that paying for software automatically makes you the legal owner.
- Write IP assignment, licensed components and reusable tools clearly into the contract.
- Keep repositories, cloud accounts and domains registered in your own name.
- Require documentation and a handover so you are never dependent on one vendor.
Who owns the code when a vendor builds your software?
Many business owners assume that paying for a build makes the software theirs. Legally it is not that simple. By default, the author of a work, which here is often the developer or their company, may hold the rights unless an agreement assigns them. Only a clear written clause transfers ownership to you.
This is why contracts matter. Without an assignment clause, you may only hold a licence to use the software, with limits on modifying or moving it to another vendor. Check how your agreement words it, and do not rely on verbal assurances or on what a proposal brochure implies.
What ownership clauses should the contract include?
The central clause is an assignment of intellectual property for the custom work to you, effective on full payment. Specify that it covers source code, designs, database schemas, documentation and any assets created for the project. Clarify moral rights, confidentiality and whether the vendor may reuse general knowledge.
Be precise about exclusions as well. Vendors often keep ownership of their pre-existing frameworks, libraries and internal tools, granting you a licence to use them within your product. That is normal, but the licence should be perpetual, include the right to modify and maintain your product, and not depend on a continuing relationship with the vendor.
- Assignment of IP in custom code, designs and documentation.
- Timing of transfer, for example on final payment.
- Licence terms for the vendor's pre-existing tools.
- Right to modify, host and maintain the software.
- Confidentiality and non-use of your business data.
How do open-source and third-party components affect ownership?
Almost every modern application uses open-source libraries and third-party services. These carry their own licences, which you do not own and cannot override. Most are permissive and cause no trouble, but a few impose conditions, especially if you distribute the software or sell it as a product.
Ask your vendor to provide a list of components with their licences. If you plan to commercialise the software, as a SaaS product or white-label offering, this list matters even more. Licence compliance is easier to arrange during the build than to untangle after a customer or investor asks.
Why do repositories, hosting and domains matter as much as the contract?
Legal ownership is of little use if you cannot reach the code. Insist that the code repository, cloud accounts, domain names, app store listings and API keys are created in your organisation's name, with the vendor given access as a collaborator. This is simple to set up on day one and painful to fix later.
Possession protects you in practice. Regular access to the repository lets you see progress, run independent checks and switch vendors if needed. If a vendor holds everything in its own accounts, you depend on its goodwill, no matter what the contract says.
- Code repository under your organisation's account.
- Cloud hosting billed to and owned by you.
- Domain registered in your name.
- App store developer accounts held by you.
- Credentials stored in a shared, controlled vault.
What handover and documentation should you require?
Software that only its authors can understand is a risk. Require setup instructions, an architecture overview, a description of the database, deployment steps and notes on integrations. Ask for a handover session where the vendor walks your team, or a new vendor, through everything.
Include a defined final delivery: tagged release, build scripts, environment configuration and test cases. Pay the last milestone against this handover. It ensures that the work is genuinely portable and that you can maintain or extend the product without starting again.
What if you are building a product to sell, or to raise investment?
If the software is your business, clean ownership is not optional. Investors and acquirers routinely check that the company owns its code and that contractors have assigned their rights. Gaps in the chain of title can delay a funding round or reduce confidence.
Keep signed assignments from every contributor, employee or contractor, maintain the component licence list, and avoid code of unclear origin. Consult a qualified lawyer on current intellectual property and contract law, because this guide describes general principles and not legal advice.
Frequently asked questions
If I paid for the software, do I own it automatically?
Not necessarily. Ownership depends on the contract. Make sure it includes an explicit assignment of intellectual property to you.
Can a vendor reuse my code for other clients?
Only if the contract allows it. Generic tools they own may be reused, but your business logic and data should stay confidential.
What if my vendor shuts down or disappears?
If the repository, hosting and documentation are in your control, you can continue with another team. Escrow arrangements are another option for critical systems.
Do I need a lawyer for this?
It is wise. A lawyer can check the wording against current law and your circumstances, particularly if you plan to sell or license the software.
Need help with this? See our Custom Software Development service or talk to Yash Parikh.