The Five Contractual Holes That Let Indian Development Teams Walk Away With Your Software
Photo: DFID - UK Department for International Development, CC BY 2.0, via Wikimedia Commons
Every week, an American founder discovers that the offshore development arrangement saving them $200,000 a year has a legal foundation resembling Swiss cheese. The code works. The invoices are paid. The relationship feels fine — right up until the day it isn't, and the founder learns that the intellectual property behind their product may not actually belong to them.
Having reviewed hundreds of US-India development agreements, we see the same failures repeat with remarkable consistency. Here are the five most common — and the specific safeguards that close each hole.
1. IP Assignments That Never Get Registered or Properly Executed
Under Indian copyright law, an assignment of future work must be in writing and signed by the assignor. Sounds simple. Yet countless engagement letters contain only a vague "work made for hire" reference — a concept borrowed from US copyright law that carries far less weight in India. Worse, some agreements grant a "license" rather than an assignment, leaving the developer as the legal owner of your product.
The safeguard: Demand a standalone intellectual property assignment agreement, executed by an authorized signatory of the Indian vendor, that expressly assigns all present and future rights in code, documentation, and derivatives. Where patents or designs may be involved, require the vendor to cooperate with filings in India and the US. Review the signatures — stamp paper formalities and witness requirements vary by Indian state, and sloppy execution has voided more than one assignment.
2. No Source Code Escrow or Repository Rights
When a development relationship collapses — vendor insolvency, a fee dispute, a lost key employee — US startups frequently discover they have no complete, current copy of their own source code. What they have is a partial repository, outdated builds, and a vendor who is no longer answering email.
The safeguard: Require continuous delivery of all source code, build scripts, and deployment documentation to a repository the startup controls, with acceptance testing at each release. For mission-critical systems, a formal escrow arrangement with defined release triggers (insolvency, material breach, abandonment) adds a second layer of protection. The cost is trivial; the alternative is rebuilding your product from scratch under duress.
3. Milestones So Vague They Enforce Nothing
"Phase 2: backend development complete" is not a milestone; it is a litigation invitation. When payments are tied to milestones that cannot be objectively verified, a US startup that withholds payment for non-delivery may itself be in breach, while the Indian vendor claims earned fees for work that was never finished.
The safeguard: Define every milestone with measurable acceptance criteria — specific functionality, performance benchmarks, documented deliverables — plus a fixed acceptance window with a deemed-acceptance or deemed-rejection mechanism. Tie payment to acceptance, not to effort or calendar days. Include a right to audit progress at reasonable intervals.
4. Data Protection Terms That Ignore Both Regimes
If your Indian team touches user data — and it almost certainly does — you are subject to obligations under US state privacy laws and, increasingly, under India's Digital Personal Data Protection Act. Agreements drafted with a one-line confidentiality clause expose startups to regulatory action on both sides of the Pacific, and to the awkward discovery that customer data was stored on uncontrolled personal devices.
The safeguard: Include a data processing addendum specifying permitted purposes, security standards, sub-processor restrictions, breach notification timelines, and audit rights. Address cross-border transfer mechanics explicitly under Indian law. Cross-reference your US privacy obligations so the vendor's commitments actually cover them.
5. No Exit Provisions — So Every Breakup Is a Hostage Situation
The most dangerous agreements are the ones that say nothing about termination. Without defined exit rights, a US startup that wants to change vendors may face demands for ransom payments, refusal to hand over code, or quiet retention of admin credentials to production systems.
The safeguard: Build a complete exit architecture: termination for convenience with defined notice, termination for cause with cure periods, a transition assistance obligation of fixed duration, a complete handover checklist (code, credentials, documentation, infrastructure access), and — critically — a survival clause preserving IP assignments and confidentiality after termination. Add non-solicitation terms protecting your team and your customers.
An Honest Word on Enforcement
A perfect agreement still needs to be enforceable. Specify arbitration with a seat outside India (Singapore is a common, pragmatic choice), and confirm the Indian entity signing is the one that actually holds the assets and the people. A contract with the wrong entity is a beautifully drafted nothing.
None of these safeguards is exotic. All of them are standard for mature cross-border technology relationships. The founders who skip them are not saving money — they are deferring a much larger invoice. Advocate Vishwanath regularly assists US startups in structuring and auditing their India-based development arrangements before the relationship, not after it, goes wrong.
