Who Owns Your Code? IP and Source Code Rights in Outsourcing

Many founders discover who owns their software only when something goes wrong. A relationship with a development vendor ends, an investor asks for a code audit, or a new engineer cannot get access to the repository. At that moment, the contract you signed months earlier suddenly matters more than any feature on the roadmap.

This guide explains how source code ownership and intellectual property (IP) work when you outsource product development. It is written for non-lawyer founders and SME owners in India and abroad. It is not legal advice, so treat it as a checklist of questions to bring to your own counsel and your development partner.

Why ownership is not automatic

A common assumption is that whoever pays for the software owns it. In many jurisdictions, including India, copyright in a work created by an independent contractor does not automatically pass to the client. Unless the agreement says otherwise in writing, the author, meaning the vendor or the individual developer, may keep the rights, and you may only hold a licence to use the work.

That gap creates real risk. Without a written assignment, you may be unable to modify the code freely, sell the company with clean title, or move to another vendor without negotiation. Investors and acquirers will ask for proof of ownership, and a vague contract slows down a funding round.

Paying an invoice and owning an asset are two separate events. The contract is what connects them.

The four layers of ownership to separate

Software is not one thing. When you negotiate, split the deliverable into layers, because each layer can have different rules.

• Custom code written for you: This is the layer you should own outright, through a written assignment of copyright that takes effect on payment.
• Vendor pre-existing tools: Reusable libraries, starter templates, and internal frameworks the vendor owned before your project. You normally receive a licence to use these, not ownership.
• Third-party and open source components: These keep their own licences. You need a list of them and confirmation that none force you to publish your own code.
• Data and content: Your customer data, uploaded files, and brand assets should always remain yours, with clear rules on export and deletion.

A good agreement names each layer. A weak one says only "all work product belongs to the client," which sounds reassuring but leaves the pre-existing tools question open and can cause disputes later.

A real-world style example

Consider an illustrative scenario. A founder hires a freelancer to build a booking app. The project goes well, and the founder launches. Eighteen months later, an investor requests due diligence. The code lives in the freelancer's personal repository, the cloud account is registered under the freelancer's email, and the contract contains no assignment clause.

The founder now has to negotiate with someone who has no obligation to cooperate and who might reasonably ask for payment in exchange for signing over rights. A deal that could have closed in weeks might stall for months. This is a hypothetical case, but variations of it are common enough that experienced advisors treat repository and account ownership as a day-one concern. Our guide on how startups can pass investor technical due diligence covers what reviewers typically ask for.

Clauses to look for in the contract

Assignment of rights

Look for explicit wording that all copyright and related rights in the custom deliverables are assigned to you, effective upon payment. Words like "licensed" or "granted a right to use" in place of "assigned" deserve a question.

Licence for pre-existing materials

If the vendor reuses their own components, the contract should give you a perpetual, irrevocable, worldwide licence to use and modify those components as part of your product. Otherwise a future dispute could make part of your app unusable.

Moral rights and contributor waivers

Individual developers may hold moral rights in their work. The vendor should confirm that every employee and subcontractor who touched your project signed agreements that pass their rights up to the vendor so they can pass them on to you.

Confidentiality and non-compete scope

Confidentiality should protect your business logic and data. Be careful, however, with non-compete clauses that are too broad, because they can be hard to enforce and may sour the relationship. A narrow clause that stops the vendor from building a direct clone using your confidential material is usually more realistic.

Warranties and indemnity

The vendor should warrant that the deliverable does not knowingly infringe anyone else's rights and that they have the authority to assign it. Indemnity wording decides who pays if a third party makes a claim.

Practical control matters as much as paper

A contract is only half the story. Practical control over the technical assets is what lets you act on your rights. Whether you pay on fixed scope or hourly, the commercial structure should not change who holds the keys. If you are still weighing structures, our comparison of fixed-price and time and materials contracts shows how payment terms and milestones interact with delivery.

• Repository: The code should live in a repository owned by your organisation, with the vendor invited as a collaborator.
• Cloud accounts: Hosting, domain, app store developer accounts, and analytics should be registered under your company, not the vendor's.
• Credentials: API keys and third-party service accounts should be in a shared secrets manager that you control.
• Documentation: Architecture notes, environment setup steps, and deployment instructions should be written as part of the project, not left in someone's head.

A numbered process to secure ownership

1. Create your own accounts first. Before the kickoff call, set up the code repository, cloud project, and developer store accounts under a company email address, and add the vendor as a team member.
2. Ask for the assignment clause in writing. Request a contract that assigns custom deliverables to you on payment and licenses pre-existing materials in perpetuity.
3. Request a third-party component list. Ask the vendor for a software bill of materials listing every library and its licence, and have it refreshed at each major release.
4. Confirm contributor agreements. Ask the vendor to confirm that every person working on your project has signed an IP agreement with them.
5. Tie payment to handover. Make the final milestone depend on delivering source code, documentation, and a working build you can deploy yourself.
6. Run a handover rehearsal. Ask a second engineer, internal or independent, to build and deploy the app from your repository using only your documentation.
7. Store a dated snapshot. Keep an archive of each release in storage you control so you always have a recoverable copy.

What happens when you change vendors

Even the best relationships end. A team changes direction, budgets shift, or you simply outgrow the partner. If ownership and access are already in your hands, switching becomes an operational task rather than a negotiation. If they are not, it becomes a crisis. Our vendor handoff checklist for startups walks through the technical steps for a smooth transition.

The handoff is also the moment when undocumented knowledge surfaces. A short, structured knowledge transfer, with recorded walkthroughs and a written runbook, protects you from the single point of failure that a lone developer represents.

Key benefits of getting this right

• Faster fundraising and exits: Clean title to the code removes a common blocker in due diligence.
• Freedom to choose vendors: You can bring in new engineers or switch partners without asking permission.
• Lower legal exposure: Documented component licences reduce the chance of an unpleasant surprise from an open source obligation.
• Better continuity: Documentation and owned accounts keep the product running when people change.
• Stronger negotiating position: A vendor who knows you hold the keys tends to keep communication professional and transparent.

Common mistakes founders make

The first mistake is relying on a verbal promise. Friendly vendors are often honest, but staff change and memory fades. The second is leaving the vendor's name on the app store listing or the cloud billing account. The third is accepting a licence where an assignment was needed, simply because the wording looked similar. The fourth is skipping the open source review, which can surface restrictive licences late in the process.

Finally, many founders wait until a crisis to read the contract. Reading it before you sign, with a short legal review, costs far less than repairing it afterwards. For illustration, a small legal review might cost a fraction of the project budget, while a disputed ownership claim could delay a funding round by months. These figures are hypothetical and will vary by project and jurisdiction.

How a responsible partner behaves

A development partner that respects your ownership will volunteer these practices instead of resisting them. They will work in your repository, document as they build, and accept an assignment clause without drama. When you evaluate vendors, treat their reaction to these requests as a signal. If you want to know how we approach delivery, you can read more about the Mavani Solution team and how we work with founders.

For teams planning a product built as a subscription platform, the same principles apply at larger scale. Our SaaS development service is structured so that clients hold their repositories and cloud accounts from the first sprint.

Conclusion

Owning your software is a deliberate outcome, not a default. Separate the layers of ownership, insist on a written assignment for custom code, keep control of repositories and accounts, and rehearse a handover before you need one. These steps cost little at the start of a project and save a great deal when you raise funding, change vendors, or sell the business. Have a qualified lawyer review your specific agreement, and share this checklist with your development partner at the very first meeting.

Frequently Asked Questions

Does paying for software mean I own the code?

Not automatically. In many jurisdictions, copyright in work made by a contractor stays with the author unless a written agreement assigns it to you. Check that your contract includes an explicit assignment that takes effect on payment, and have a lawyer review it.

What is the difference between assignment and licence?

An assignment transfers ownership of the rights to you. A licence only grants permission to use the work, usually with limits. For custom code, founders generally want an assignment. For the vendor's reusable tools, a perpetual licence is common.

Who should own the repository and cloud accounts?

Your company should. Create the code repository, cloud project, domain, and app store accounts under your own organisation and invite the vendor as a collaborator, so you keep control if the relationship ends.

What are open source risks in outsourced code?

Some open source licences require you to share modifications or restrict commercial use. Ask the vendor for a list of third-party components and licences, and review it before launch or fundraising.

How can I test that a handover will work?

Ask a second engineer to build and deploy the app from your repository using only your documentation. If they succeed without help from the original vendor, your handover is in good shape.