The fear people voice about offshore development is that somebody will steal their idea. The thing that actually costs companies money is duller and far more common: they paid for software for eighteen months and never legally owned it.
Nobody stole anything. The paperwork was just never done, and it only surfaced when it mattered, during an acquisition, a funding round, or the week they tried to change vendors.
This is not legal advice and we are not lawyers. It is the list of places we have watched ownership break, and what a contract should say about each. It sits alongside our honest list of offshore risks, where this is the one we called the real version of the idea-theft fear.
Key Takeaway: Paying an invoice does not transfer copyright. In both US and Indian law the author owns the work by default, and a contractor is not an employee, so ownership moves only through an explicit written assignment. Four things need to be in your name from day one: the repository, the Apple and Google developer accounts, the cloud and third-party service accounts, and the domain. Take assignment at each invoice rather than at project completion.
Paying for It Is Not the Same as Owning It
This is the part that surprises people, and it is true on both sides of the engagement.
Under US law, “work made for hire” is much narrower than the phrase suggests. It covers work by an employee within the scope of their employment, or specially commissioned work falling into one of nine enumerated categories, with a signed agreement. Software written by an outside contractor is generally not in those categories. The US Copyright Office sets this out in Circular 30. So writing “work for hire” into a contract with a vendor does not, by itself, do what people assume it does. You need an assignment clause.
Indian law reaches the same place by a different route. Under the Copyright Act 1957, the author is the first owner of copyright, with an exception for work made under a contract of service, meaning employment. An agency you hire is a contract for service, not of service. Absent a written assignment, the vendor owns the copyright in what it wrote. The Indian Copyright Office publishes the Act.
None of this is specific to offshore work. A local contractor two miles away creates the same gap. What offshore changes is the cost of fixing it afterwards, since the remedies all assume you can practically compel somebody in another jurisdiction.
Early-stage companies get caught most often, because the paperwork feels like overhead when the product does not exist yet. If you’re scoping a first version, this is the cheapest moment in the product’s life to get it right, and the assignment costs nothing to include while the contract is still being drafted.
The practical upshot is the same in both jurisdictions. Copyright sits with whoever wrote it until a signed document moves it. An invoice marked paid is not that document.
One Indian wrinkle worth knowing, because it surprises US buyers. Section 57 of the Copyright Act gives authors moral rights, the right to be identified and to object to distortion of the work, and those do not transfer with an assignment. In practice this almost never affects software. It’s raised occasionally in negotiation and it is not a reason to walk away from an otherwise sound contract.
The Chain of Title Behind Your Vendor
Here is the gap that catches even careful buyers. Your contract with the vendor is one link. It is not the whole chain.
The vendor can only assign what it owns. If the engineers who wrote your code are employees of that company, working within the scope of their employment, the vendor owns their output and can pass it to you cleanly. If any of them were contractors, freelancers, or staff at a subcontracted firm, then the vendor needed its own written assignment from each of them. Plenty of small agencies have never done this, not out of bad faith but because nobody told them either.
The result is an assignment clause that reads perfectly and transfers less than it claims. You discover it when an acquirer’s lawyer asks the vendor to evidence its own chain of title and the answer is a long silence.
Two sentences fix it. Ask the vendor to warrant that it holds all necessary rights in the work, including from any contractor or third party involved, and to confirm that no part of the work will be performed by anyone outside the contracting entity without your written consent. Reputable firms sign this without blinking. It also quietly solves the undisclosed subcontracting problem, since a warranty makes hiding it a breach rather than an omission.
Assignment at Completion Is the Wrong Trigger
Most contracts we see assign IP “on completion of the project” or “on final payment”. That sounds reasonable until you consider when ownership actually matters.
It matters when things go wrong. A dispute at month four, a vendor who stops responding, a project cancelled at seventy percent. Those are precisely the moments when assignment on completion means you own nothing, having paid for four months of work. On a build running to a normal timeline of three to six months, “completion” is a long way from the first payment.
Ask for assignment at each invoice. Work paid for is work owned. It costs the vendor nothing if they intend to deliver, and it removes the single worst outcome for you. A vendor who resists this is telling you how they expect the engagement to end. Milestone payments make this natural, which is one more argument for structuring the engagement that way from the start, as our hiring guide sets out.
Watch for background IP carve-outs alongside it. Some agreements assign the deliverable but retain ownership of the frameworks, libraries or internal tooling used inside it. That can be entirely reasonable when it is genuinely reusable infrastructure, and it becomes a problem when the carve-out is wide enough that you cannot maintain your own app without the vendor. Read what is excluded, not just what is granted.
The test to apply is simple. If the carve-out is real, ask whether you get a perpetual, irrevocable, royalty-free licence to use and modify that background IP as part of your app. A yes makes the carve-out harmless. A no means your ongoing maintenance depends permanently on one supplier, whatever the assignment clause says about the rest.
The Four Things That Must Be In Your Name
Contracts get the attention. In practice ownership breaks in the accounts, not the clauses.
The Repository
The code should live in a GitHub, GitLab or Bitbucket organisation your company owns, from the first commit, with the vendor added as collaborators. Not the vendor’s organisation with a promise to transfer at the end.
The difference is not paranoia. Code sitting in the vendor’s account until handover means you are relying on a handover going smoothly, and the times that matters most are exactly the times it will not. It also means you cannot see commit history, so you have no way to know whether four engineers are working on your project or one is working on it on Fridays.
If you are mid-project and the repository is not yours, this is the first thing to fix, and it is a ten minute job for anyone willing to do it.
The Apple and Google Developer Accounts
Publish under accounts registered to your company. Not the vendor’s, ever.
If your app is live under an agency’s Apple Developer account, they control the listing, the reviews, the ratings history and the ability to ship an update. Migrating an app between Apple accounts is possible but slow, and it requires the current holder to cooperate. If you are changing vendors because the relationship soured, cooperation is the thing you no longer have.
The same applies to Google Play, with an added wrinkle: the app signing key. If the vendor holds it and you lose access, you cannot ship an update to your existing users at all. You would publish a new listing and start from zero installs and zero reviews.
We wrote up the mechanics of both in the Apple Developer account and Google Play Console guides, and the publishing cost breakdown covers the fees. The registration cost is trivial. Do it in your own name before development starts, ideally before the first beta build goes out, because testers installing from the wrong account is how this gets discovered late.
The Cloud and Service Accounts
This one gets missed because it is spread across a dozen places. Firebase, AWS or Google Cloud, the payment gateway, the analytics tool, the crash reporter, the push notification service, the SMS provider, the maps API key.
Each of these should be an account your company owns, with the vendor invited. When they sit in a vendor’s account you have no billing visibility, no way to rotate a key, and no continuity if the relationship ends. It is also how companies end up unable to explain to an auditor where their user data actually lives.
For regulated products this stops being housekeeping and becomes a compliance requirement. A fintech app needs demonstrable control over payment infrastructure, and anything in healthcare needs it over anything touching patient records. Our healthcare development guide covers how those obligations differ between markets.
The Domain and DNS
Register it yourself. If a vendor offers to handle it as a convenience, decline politely. Domain recovery from an unwilling third party is among the slowest problems in this entire list.
Open Source Is the Ownership Problem Nobody Asks About
Every modern app pulls in dozens of open source libraries, and their licences travel with them.
Most of what you will encounter is permissive. MIT, Apache 2.0 and BSD let you use the code commercially with attribution and little else. That is fine.
The one to watch is strong copyleft, GPL and AGPL. If a library under those licences is linked into your application, the licence can require you to release your own source under the same terms when you distribute it. For an internal tool that may not matter. For a commercial product it can be a serious problem, and it is the kind of thing discovered during acquisition due diligence rather than during development.
The risk grows with the dependency count, which is why it deserves attention on cross-platform builds where the JavaScript and Dart ecosystems pull in transitive packages by the hundred. Nobody reads them all. A tool that reads them for you, run at each release, is the only workable answer, and it belongs in the development process rather than in somebody’s memory.
Ask your vendor for a dependency licence report. Any competent team can produce one in an afternoon from the tooling they already use. If they have never thought about it, that itself is useful information, and it belongs on the list of things worth probing while choosing a development company.
Code Your Vendor Did Not Exactly Write
New, unsettled, and worth a paragraph because nobody’s contract mentions it yet.
Most working developers now use AI assistants. Your app almost certainly contains code that was suggested by a model and accepted by a human, and neither your contract nor your vendor’s employment agreements say anything about it.
The US Copyright Office’s position is that purely machine-generated output is not copyrightable, and protection requires human authorship. Where a developer prompts, reviews, edits and integrates a suggestion, there’s a reasonable argument that the result is authored. Where somebody accepted a large block untouched, that argument is weaker. Nobody has litigated this to a clean answer for software.
What this means practically is narrower than it sounds. You are unlikely to lose ownership of your app. What you can lose is the ability to claim exclusivity over some specific part of it, which matters if you were planning to defend a distinctive feature.
The more immediate issue is licence contamination. A model trained on public repositories can reproduce a recognisable chunk of GPL code, and it arrives with no licence header attached. That’s the same copyleft problem as above, arriving through a door nobody is watching.
Two practical asks. Have the vendor confirm that AI-assisted code is reviewed before it’s committed, which any decent team does anyway. And include AI-suggested code in the same assignment and warranty language as everything else, so whatever rights exist come to you. It costs nothing to add now and it will look prescient in three years.
Worth asking developers about directly, too. “How do you use AI tools, and what do you do differently because of them” is a genuinely revealing interview question in 2026, and our list of questions for mobile developers has others in that shape. The answer you want involves review and scepticism. The answer that should worry you is either “we don’t” or “constantly, it’s brilliant”, because both suggest nobody has thought about it.
What Due Diligence Actually Asks For
Most of this stays theoretical until somebody buys you, invests in you, or performs a technical audit. Then it becomes a list, and the list is fairly consistent.
An acquirer’s counsel will ask for the signed assignment covering every contributor, the vendor’s warranty that it held the rights it assigned, evidence of who controls the repository and for how long, confirmation that store accounts and signing keys are in the company’s name, an open source dependency report with licences, and confirmation that no copyleft licence is linked into the distributed product.
Assembling that in a week is straightforward if the paperwork was done as you went. Reconstructing it retroactively across an eighteen month engagement and two vendors is where deals slow down and valuations get adjusted. We have watched a funding round stall for six weeks over a repository that was still in an agency’s GitHub organisation. Nothing was contested. It simply took that long to prove.
StockGenie is a useful counter-example on the other side of this. Built in two months, live on the Play Store, and every item on that list was in place before launch because it was set up that way at the start rather than assembled afterwards.
Keep an ownership folder from day one. The signed assignments, the account registration confirmations, the licence report from each release. It’s twenty minutes a quarter and it is the cheapest insurance in this article.
Whoever holds your ongoing support should be adding to that folder as part of the arrangement rather than as a favour. Ownership is not a thing you establish once at launch. Every release adds code, and every piece of new code needs to arrive under the same terms as the last.
What to Ask Before You Sign
Six questions, all answerable in a sentence. A vendor who cannot answer them quickly has not thought about your interests.
- Which organisation will the repository live in, and whose account is it
- When does IP assignment take effect, at each invoice or at completion
- What background IP or tooling are you carving out of the assignment
- Whose Apple and Google developer accounts will the app publish under, and who holds the signing key
- Which third-party service accounts will be registered to us rather than to you
- Can you give us a dependency licence report before launch
Our fuller offshore contract checklist covers the commercial terms alongside these, including exit conditions and the tax paperwork a US company needs. Ask all six on the first call rather than sending them to a lawyer later. They cost you nothing and they sort a shortlist faster than any reference check. Put them to everyone you’re considering, including us and including the firms on our list of Pune companies.
If You Are Already Mid-Project
None of this is unrecoverable, and it is much easier to fix now than at the point you need it.
Work through it in this order, because it is roughly the order of how painful each becomes later:
- Get the repository transferred or mirrored into your organisation. Immediate, and it protects everything else.
- Move the store accounts, or at least confirm who holds the Play signing key. Slow, so start it early.
- Sign an assignment covering work already delivered. Most vendors will do this without argument. Reluctance is the answer to a question you did not ask.
- Inventory the service accounts and move the ones that matter, starting with anything holding user data.
- Request the dependency licence report.
Doing all five takes a couple of weeks of low-effort chasing and removes almost every version of this problem.
Our Own Position, So You Can Judge It
Everything above is what we do by default, which is easy to say on our own website, so here is the checkable version. Repositories are created in the client’s organisation before the first commit. Store accounts are registered to the client, and we ask for that during onboarding rather than after. Assignment is at each invoice. If a client ends an engagement, they already have everything, because there was never a handover step to depend on.
That is also the honest reason we recommend it: an engagement where the client owns everything from the start has nothing to argue about at the end. It’s how our dedicated developer engagements are structured whether the team is React Native, Android or iOS, and you can see the work itself rather than taking our word for the process.
If you want a second opinion on a contract you have been sent, or you are mid-project and unsure what you actually own, get in touch. If we think the answer is that you are fine, we will say so, and if you are not, you will at least know which of the five to start with.