Every founder who sends development offshore carries the same picture somewhere in the back of their mind: two years of product work sitting in another country, under another legal system, held by people they have mostly met over video. What if they keep it? What if pieces of it surface in a competitor’s product? What if enforcing the contract means a courtroom ten time zones away? These are reasonable fears, and the industry’s standard answer — a thicker contract — addresses them least well. What follows is education, not legal advice; when it comes to the contract itself, pay a lawyer who knows cross-border IP.
Structure protects you better than language
The strongest protection available has nothing to do with clauses: arrange things so the code never lives anywhere you would need to recover it from. Repositories created in your GitHub organisation before the first commit. Production running in your cloud accounts, on your billing, under your root credentials. CI/CD wired into your infrastructure, not the vendor’s. Under that arrangement there is no handover event at which your IP changes hands, because it never left your hands. A dispute about returning assets cannot happen when there is nothing to return — which is the whole argument for being exit-ready by design rather than exit-hopeful by contract.
For AI work this matters twice over. Prompts, golden datasets, eval harnesses and fine-tuning data are the accumulated judgement of your system — often more of the real value than the glue code around the model. They belong in your repos and your accounts like any other source. A vendor who keeps them has kept the product and handed you the wrapper.
The contract layer: what it does and where it stops
Contracts still matter; they just work best defending a position you already hold. Three things to look at closely. First, the assignment itself: you want present-tense assignment language — the vendor hereby assigns the work as it is created — not a promise to assign later, which leaves a window where the vendor owns your codebase. Second, “work for hire”: in US law that doctrine reliably covers employees, but software written by an outside contractor often falls outside it, which is exactly why explicit assignment language exists. If a vendor’s template leans on work-for-hire alone, that is worth a conversation with your lawyer. Third, jurisdiction: a governing-law clause naming Delaware is comforting until you ask how a Delaware judgement gets enforced against an entity with no US assets. What matters is whether the counterparty is anchored somewhere your judgement has teeth, and whether there is a corporate structure behind it that can be held to account.
NDAs deserve one honest sentence: they define what is confidential and they signal seriousness, but they are policed after the harm, not before it. An NDA is a deterrent, not a lock. Treat it as one layer, never the plan.
The operational layer: access, offboarding, audit
Day to day, IP protection is an access-control problem. Engineers get least-privilege access through your identity provider, so revoking a person is one action in one console, not a scavenger hunt across services. Secrets live in your secret manager and rotate when anyone rolls off. Offboarding is a written procedure with a deadline measured in hours, rehearsed before it is ever needed in anger. And the audit trail mostly builds itself if the structure is right: when every change enters your repos through a reviewed pull request signed off by a named engineer, you hold a complete, timestamped provenance record of who wrote what, when, and who approved it. That record is worth more in a dispute than any recital in the contract.
Questions that sort vendors quickly
- Whose org hosts the repos, from the first commit? — “We transfer everything at the end” is the wrong answer.
- Whose cloud accounts run production? — Billing, root and IAM should be yours.
- Is the assignment present-tense, and does it cover AI assets? — Prompts, datasets, evals, by name.
- What is the offboarding procedure when an engineer rolls off? — If there is no written answer, there is no procedure.
These four fold into a longer due-diligence list we keep in the vendor lock-in checklist — the overlap is not a coincidence, because lock-in and IP exposure are the same disease at different stages.
How our setup answers each layer
Structurally: your repos and your cloud from day one — we work inside them and never hold them, and for AI systems the prompts, golden datasets and eval suites are versioned in your repos beside the code they govern. Contractually: Hazesoft Technology Private Limited is the internal engineering team of HDL Group, a Swedish group — the organisation behind your team sits inside a European corporate structure, not behind a brass plate you would struggle to locate. Operationally: named engineers, review gates on every merge, and an engineer’s sign-off on everything that ships, which means your audit trail is a by-product of how we work rather than something assembled for a dispute.
If you want to pressure-test your current setup — or a vendor’s proposed one — against these layers, book an hour with a tech lead. A technical call, not a sales call.