Many business owners find out who really controls their software only when they try to change vendors. The code sits in the developer's personal GitHub account, the server is billed to the agency's card, the domain is registered in someone else's name, and the only documentation is in one engineer's head.
This checklist covers the three parts of real ownership: the contract terms, the technical handover and a simple way to verify that what you received actually works. It applies whether you are starting a project or closing one. This is general information, not legal advice; confirm the contract wording for your case with your lawyer.
Quick answer: To own custom software in practice you need three things: a written agreement that assigns copyright and IP in the deliverables to your company, the complete source code with history in a repository your company controls, and owner-level access to every account the software runs on. Verify the handover by having someone other than the original developer build and deploy the software from what you received.
Why paying for software is not the same as owning it
Under Indian copyright law, code written by your own employees in the course of their job generally belongs to your company. Code written by an outside firm is different: the author is usually the first owner, and ownership moves to you through a written assignment. Without that document, you may only have an implied right to use the software, which becomes a problem when you want to modify it, sell the business or license the product to others.
The assignment should also state its scope clearly. An assignment that is silent on duration or territory can be read narrowly, so the usual practice is to state that rights are assigned worldwide and for the full term of copyright.
Contract clauses to check before you sign
| Clause | What it should say | Watch out for |
|---|---|---|
| IP assignment | All rights in code, designs, database schemas and documents are assigned to your company as each milestone is paid | Wording that grants only a “licence to use” |
| Vendor's existing components | Reusable libraries the vendor already owned are listed, with a perpetual, royalty-free licence for you | An unlisted in-house “framework” you cannot use with another vendor |
| Open-source and third-party parts | A list of components and their licences is delivered with the code | Licences with obligations that conflict with how you plan to distribute the product |
| Confidentiality | An NDA covering your data, business rules and source code | An NDA that covers only the vendor's information |
| Handover deliverables | A defined list of what is handed over at each milestone and at exit | “Source code will be provided on request” |
| Termination and exit | What you receive for paid work if the contract ends early, in what format and by when | No exit clause at all |
The technical handover checklist
Ask for these items in writing, and tick each one off as you receive it:
- Repository: a Git repository in your company's GitHub, GitLab or Bitbucket organisation, with full commit history and all branches. A zip file by email is not a handover.
- Build and deployment: a README that explains local setup, build scripts, CI/CD pipeline configuration and container files.
- Configuration: a list of every environment variable and secret, with the values shared through a password manager, never committed to the repository.
- Database: schema, migration scripts, an entity relationship diagram, a recent backup and written restore steps.
- Infrastructure: cloud, domain, DNS, SSL, email-sending, SMS and payment gateway accounts registered in your company's name, with your staff as owners.
- Mobile apps: Google Play Console and Apple developer accounts in your company's name, with app signing set up so that you, not the vendor, control releases.
- Documentation: architecture document, API documentation, admin guide, user manuals and standard operating procedures.
- Quality records: the automated test suite, test data, the latest security test report, and the list of known bugs and pending work.
Open-source components: what you can and cannot own
Most modern applications are built on open-source frameworks and libraries. You will not own those parts, and that is normal. What matters is that their licences allow your use. Permissive licences such as MIT, BSD and Apache 2.0 generally allow commercial use if you keep the copyright and licence notices. Copyleft licences such as the GPL can require you to share source code of derived work when you distribute the software, and the AGPL extends that to software offered to users over a network.
Ask the vendor for a dependency list with licences, sometimes called a software bill of materials. If you plan to sell or distribute the product, have it reviewed before launch rather than during investor due diligence.
How to verify the handover works
- Ask a developer who did not work on the project, internal or independent, to clone the repository and build it on a clean machine using only the README.
- Deploy that build to a fresh staging server and confirm it matches production by version tag or commit reference.
- Restore the database backup to staging and check that the application runs on it.
- Rotate all passwords and API keys, remove access the vendor no longer needs, and keep only what an ongoing support contract requires.
- Sign a short handover acceptance note listing what was received, and release the final payment after this check, not before.
Common mistakes to avoid
- Letting the vendor create cloud and app store accounts on their own email addresses to “save time”.
- Accepting a white-label product without realising you are licensing it, not buying it. That can be a fair deal, but it should be a conscious one.
- Waiting until the end of the project to ask for the repository, instead of having it in your account from day one.
- Assuming the person who built the software will always be available to explain it.
If you are still deciding whether to build at all, our comparison of custom software and off-the-shelf software covers that choice.
How EthicsComputer can help
On our custom software development projects, source code and IP are handed over to the client, and we sign an NDA on request before discovery. If you are taking over code from another vendor, legacy software modernization starts with an audit of what you have, and a source code security audit checks it for security flaws. For the contract itself, legal agreement drafting can help with IP and exit clauses. You can also review what a custom software engagement with full IP transfer includes before you speak to us.
Planning a custom build and want ownership settled from day one?
Tell us what you need built, or what you need taken over, and we will explain exactly what you will receive at each milestone.
About the author
Vinay Grover founded EthicsComputer in Rohtak, Haryana in 2018 and leads its cybersecurity, software and AI work for clients across India and abroad. EthicsComputer is ISO 9001, ISO/IEC 27001 and ISO 20000-1 certified.
