How to Build an In-House IP Engine Offshore
Most companies treat offshore intellectual property as a legal problem. They get the assignment clauses right, confirm that work for hire provisions hold, and consider the matter settled. The contracts matter, but they are the smallest part of the problem, and getting them right while getting everything else wrong is the most common way companies end up owning the paperwork for IP that does not exist.
The real question is structural. Intellectual property is produced when a team is given a problem rather than a specification, has the seniority to choose an approach, and holds the context long enough to make a non obvious decision. A team that receives detailed instructions and executes them faithfully will produce work you own outright and that is worth very little, because anyone could have produced it given the same instructions.
This guide covers both halves: the legal and entity structure that makes ownership unambiguous, and the operating design that makes there be something worth owning.
Key points
- Ownership of IP is settled by entity structure and contracts; creation of IP is settled by scope and seniority
- An owned entity gives a cleaner IP position than a vendor or contractor arrangement
- Specification driven work produces almost no defensible IP regardless of who owns it
- IP creation requires problem ownership, senior judgement and continuity of context
- Document the invention trail as you go, because reconstructing it later is expensive and often impossible
First, the part that is genuinely legal
The legal position needs to be unambiguous before any work starts, and it differs materially depending on how the offshore team is engaged. This is the part most companies do handle, but the differences between engagement models are often underestimated.
In an owned entity model, the offshore company is a subsidiary of the parent and the engineers are its employees. Indian employment contracts assign work product to the employer, and an intercompany agreement assigns it onward to the parent. The chain is short, the parties are related, and there is no counterparty with an incentive to dispute it later.
In a vendor or contractor model, the chain runs through a company whose interests are not aligned with yours. Assignment still works when drafted properly, but you are relying on a third party’s employment contracts with people you did not hire, and on that third party remaining solvent and cooperative. Where the vendor reuses components across clients, which is normal commercial practice, the boundary between your IP and their platform becomes a matter of interpretation.
| Engagement model | Who employs the engineer | IP chain | Practical risk |
|---|---|---|---|
| Owned entity (GCC) | Your subsidiary | Employee to subsidiary to parent | Low, provided intercompany agreements exist |
| Employer of record | EOR provider | Employee to EOR to you | Moderate, depends on EOR contract quality |
| Staffing or contractor | Staffing company | Employee to staffing firm to you | Moderate to high, especially on reuse boundaries |
| Outsourced development | Vendor | Employee to vendor to you | Highest, background IP and reuse commonly retained by vendor |
This is a general structural comparison and not legal advice. Take qualified Indian and home jurisdiction counsel on your specific arrangement.
The clauses worth checking carefully
Assuming an owned entity, the drafting work is modest but specific. The failures tend to cluster in the same few places.
- Employment contracts include present tense assignment of work product, not a promise to assign later
- Invention assignment covers work created using company resources or relating to company business
- An intercompany agreement assigns the subsidiary’s IP to the parent on defined terms, and is actually executed rather than drafted and filed
- Transfer pricing treatment of the IP assignment is reviewed, because tax authorities will look at it
- Contractor and consultant agreements include equivalent assignment, since these are frequently overlooked
- Open source policy is defined and enforced, because licence contamination is the most common real world IP problem
- Moral rights waivers are included where the jurisdiction recognises them
Now the part that actually determines whether IP exists
With the legal structure settled, the harder question begins. Intellectual property is not created by ownership; it is created by judgement. A team that is told precisely what to build has had the judgement removed from its work, and what it produces is an implementation rather than an invention.
This is why so many companies with impeccable IP paperwork find they have accumulated nothing defensible after three years offshore. Every line of code is assigned correctly and none of it embodies a decision that a competitor could not trivially replicate. The paperwork was never the constraint.
The four conditions for IP creation
Across capability centres that genuinely produce owned intellectual property, four conditions are consistently present. They are structural rather than cultural, which means they can be designed for.
The team receives an outcome to achieve rather than a design to implement. If the approach is specified onshore, the inventive step happened onshore and the offshore team is executing it.
Non obvious technical decisions require people who have made enough obvious ones. A team without genuine senior depth will produce competent conventional solutions, which is precisely what is not patentable or defensible.
Invention usually arrives after long exposure to a problem. Teams rotated across projects every quarter never accumulate the depth from which non obvious solutions emerge.
If every technical decision is reviewed against a delivery schedule, the team will choose the safe path every time. Safe paths are by definition the ones already known.
What offshore IP actually looks like in practice
Patents are the form people imagine and the least common in practice. Most valuable IP created in capability centres is not patented and would not be patentable. That does not make it less defensible commercially, and in many cases it makes it more so, because it is harder to inspect from outside.
- Internal platforms and frameworks that shorten every subsequent build
- Proprietary data pipelines, feature stores and the models trained on them
- Domain specific tooling that encodes hard won operational knowledge
- Architecture and design decisions that create durable performance or cost advantage
- Operational runbooks and automation that materially reduce incident cost
- Trade secrets: methods and configurations that are valuable precisely because they are not published
Building the invention trail as you go
If you may ever want to patent, defend or sell the IP, the evidence trail matters as much as the artefact. Reconstructing who invented what and when, three years after the fact and across an attrition cycle, is expensive and frequently impossible.
The good news is that most of the trail is a by product of ordinary engineering practice. It only needs to be retained deliberately rather than allowed to age out of whatever tool it lives in.
Retain design records
Architecture decision records, design documents and the discussion that led to each choice. Note the alternatives considered and why they were rejected, because that is what evidences a non obvious step.
Keep version control history intact
Do not squash away the history that shows when and by whom a component was developed. Retain repositories after projects end rather than archiving them out of reach.
Run an invention review
A short session where the team identifies anything created that quarter which is novel, valuable and not publicly known. Most quarters produce nothing, which is expected and fine.
Capture context before exit
Attrition is the main way invention context is lost. A structured handover that records what someone knew, not just what they were working on, is the cheapest IP insurance available.
Review the portfolio
Decide deliberately what to patent, what to hold as a trade secret, what to publish for recruiting advantage, and what to retire. Making no decision means defaulting to trade secret without any of the protections a trade secret needs.
The mistakes that quietly destroy an IP position
None of these are exotic and all of them are common. Each one converts a potential asset into ordinary work product.
- Specifying the solution onshore and sending the implementation offshore, which relocates the inventive step to the wrong side of the arrangement
- Rotating engineers across projects frequently enough that nobody holds a problem long enough to solve it non obviously
- Staffing to a cost per head target that removes the senior judgement required for non obvious decisions
- Allowing uncontrolled open source use, where licence terms can compromise proprietary components
- Using contractors without equivalent assignment clauses, which creates gaps in an otherwise clean chain
- Never running an invention review, so novel work is simply absorbed into the codebase and forgotten
IP ownership is decided at the design stage,By the time you are asking a lawyer whether you own something, the answer was determined months earlier by how the work was scoped, who was hired to do it, and whether they were allowed to make a decision.
Frequently asked questions
Do we own IP created by an offshore team by default?
In an owned entity with properly drafted employment contracts and an executed intercompany agreement, ownership is normally clear. In vendor or contractor arrangements it depends entirely on the contract, and background IP and reuse provisions frequently leave the vendor retaining more than the client expects. This is a general description rather than legal advice; take qualified counsel in both jurisdictions.
Is an owned entity necessary to protect IP?
Not strictly, but it produces the shortest and least disputable chain of title, and it removes a counterparty whose commercial interests may diverge from yours. Where the offshore team is expected to create genuinely valuable IP rather than execute defined work, the entity route is materially safer.
Can Indian engineers be named as inventors on patents?
Yes. Inventorship follows actual contribution to the inventive concept regardless of location, and it is a factual question rather than a commercial one. Assignment then transfers the rights to the company. Misnaming inventors to simplify a filing is a serious defect that can invalidate a patent.
What if the team is doing valuable work that is not patentable?
That is the normal case, and it is not a problem. Internal platforms, data pipelines, domain tooling and operational automation are rarely patentable and are frequently the most commercially valuable output. Protect them as trade secrets with appropriate access control and confidentiality obligations.
How does open source affect our IP position?
It is the most common practical problem. Copyleft licences can impose obligations on code that links to or derives from them, which can compromise a proprietary component. A defined open source policy with automated licence scanning in the build pipeline is inexpensive and prevents the majority of these issues.
How long before an offshore team starts producing real IP?
Rarely before month nine, and commonly between twelve and twenty four months. The constraint is continuity of context rather than talent. A team needs sustained exposure to a problem before it can produce a non obvious solution to it, which is why frequent rotation is so damaging.
Does a small centre produce less IP?
Not proportionally, and often the reverse. A small senior team with problem ownership frequently produces more defensible IP per head than a large centre executing specified work, because the conditions for invention are seniority and ownership rather than headcount.
What is the single most effective thing we can do?
Give the team a problem instead of a design. Every other measure, including the contracts, the reviews and the documentation, is protecting or recording value. Only this one creates it.
Sources & further reading
- World Intellectual Property Organization — https://www.wipo.int/
- NASSCOM — https://nasscom.in/
- Deloitte — https://www.deloitte.com/
- McKinsey & Company — https://www.mckinsey.com/
Own what your offshore team builds
Hexominds sets up capability centres as owned entities with the IP position, contracts and governance settled before the first line of code is written.