The most expensive assumption in software procurement is that paying for code makes you its owner. In most jurisdictions it does not. Copyright sits with the author by default, and it moves to you only because a contract says so, in specific language.
Geography is not the variable here. An offshore team and a team down the road are governed by the same principle — the contract decides. What changes offshore is how much harder it is to do anything about it if the contract is weak.
This is a buyer’s checklist, not legal advice. Have a lawyer in your own jurisdiction review anything you sign.
The clause to look for
You want an explicit assignment of all work product created under the engagement, and you want to check three things about it.
What it covers. Source code is the obvious part. The clause should also reach documentation, designs, database schemas, build scripts, infrastructure configuration and test suites. A codebase you own with build tooling you do not is not a codebase you can run.
When it takes effect. This is the one that matters most, and it is covered below.
Who is bound by it. The company you contract with must have obtained assignment from every individual who wrote anything — employees and, crucially, any subcontractors. A vendor that cannot confirm this has a gap between what it promises you and what it actually holds.
Refuse transfer on final payment
The single most common weak clause assigns ownership “upon final payment”. It sounds like ordinary commercial protection and it is not equivalent to it.
Under that wording, until the last invoice clears, the code is theirs. Any dispute — about scope, about quality, about a delay that was arguably your fault — becomes a dispute in which they hold the asset. That is not a payment term, it is leverage over an asset you have already substantially paid for.
What to ask for instead: assignment effective as the work is created, with the vendor’s protection coming from ordinary remedies for non-payment. A vendor genuinely worried about being paid can ask for milestones, deposits or escrow. Those protect them without holding your product.
Vendors who push back on this usually do so out of habit rather than position. It is worth asking.
Ownership of the code is not the same as control
You can own every line and still be unable to operate the system. The things that decide that are rarely in the IP clause at all:
- Repositories — in your organisation’s account from day one, not transferred at handover.
- Cloud accounts — infrastructure in accounts you own, with the vendor granted access, rather than the reverse.
- Domains and DNS — registered to you. This one catches people surprisingly often.
- Third-party accounts and API keys — in your name, billed to you.
- Deployment pipelines and secrets — documented, and reachable without the vendor.
The test is simple: if the relationship ended badly tomorrow, could you deploy on Monday? If the answer depends on their goodwill, the IP clause is not doing the work you think it is.
Open source and pre-existing components
No custom build is entirely custom. Vendors reuse their own libraries and pull in open-source packages, both of which are normal and fine — provided they are declared.
Ask for a written list of pre-existing vendor components with a perpetual, transferable licence to use them, and a dependency list with licences. The licence type matters: permissive licences are unproblematic, while copyleft terms can impose obligations on how you distribute your own product. Find out before launch rather than during a due diligence process.
Jurisdiction, honestly
A contract is worth what enforcing it would cost. Enforcing an assignment clause across borders is slow and expensive enough that, for most mid-market projects, it is not a realistic remedy.
That argues for two things rather than for avoiding offshore delivery. First, contract with an entity in a jurisdiction where enforcement is practical for you — many offshore delivery teams operate through a local entity precisely for this reason, and it is worth asking which entity you are signing with. Second, rely on operational control rather than on legal remedy: if repositories, cloud accounts and domains are yours from the start, the assignment clause is a backstop rather than your primary protection.
Common questions
Do I own software I paid a developer to build?
Not automatically. Copyright generally sits with whoever wrote it, and transfers to you only through an explicit assignment clause. Paying an invoice is not, by itself, an assignment of intellectual property.
What is wrong with IP transferring on final payment?
It means that until the last invoice clears, the vendor owns the asset you have largely paid for — so any dispute is one they hold leverage in. Ask for assignment as the work is created, with the vendor protected by milestones, deposits or escrow instead.
Does offshore development put my IP at more risk?
Not because of geography, which does not determine ownership. The contract does. What changes offshore is that enforcing a weak contract across borders is slower and costlier, so operational control — your repositories, your cloud accounts, your domains — matters more than the clause.
What besides source code should the contract cover?
Documentation, designs, database schemas, build scripts, infrastructure configuration and tests, plus a declared list of any pre-existing vendor components with a perpetual transferable licence, and a dependency list with open-source licences identified.
We contract through our US entity, with engineering in Islamabad, and repositories and cloud accounts sit with the client from day one. See custom software development, or read how to choose a custom software development partner.
