Nearly every article about hiring offshore developers is about finding good engineers. Almost none are about the paperwork, which is odd, because the engagements we have watched fail rarely failed on code quality.
They failed because the client did not own the repository. Or the app was published under the agency’s store account. Or nobody had agreed what happens when somebody wants out. Those are contract problems, and they are cheap to prevent and expensive to unwind. Contracts are only half of it, and the risks that no clause can remove are covered separately in an honest list of offshore development risks.
This assumes you have already picked somebody. If you are earlier than that, how to hire app developers in India covers the search and the screening, and choosing a development company covers the shortlist. Come back here once you have a draft agreement in front of you.
Key Takeaway: Six items decide most of it. Who owns the code and when it transfers, whose store accounts the app publishes under, what overlap hours are committed, what happens on termination, whether the vendor supplies a W-8BEN-E, and who carries liability for a data breach. Get all six written down before any money moves.
Intellectual Property, and When It Actually Transfers
The clause you want assigns every deliverable to your company on a work-for-hire basis, and it should transfer at each invoice rather than at project completion. The difference matters. If assignment happens only at the end, then a dispute halfway through leaves you with no rights to work you have already paid for.
Watch for background IP carve-outs. Some agreements assign the deliverable but retain ownership of frameworks, libraries or tooling the vendor used inside it. That can be reasonable if it is genuinely reusable infrastructure. It becomes a problem when the carve-out is broad enough that you cannot maintain your own app without them.
Ask where the repository lives. It should be an organization your company controls from the first commit, with the vendor added as collaborators. Code sitting in the vendor’s GitHub until handover means you are relying on a handover going smoothly, and the times it matters most are exactly the times it will not. The full picture of what can go wrong with ownership, including the store accounts and the open source licences nobody checks, is in who owns your code when you hire an offshore team.
Store Accounts, Which Nobody Thinks About Until It Is Too Late
This is the item we have seen cause the most damage and the one buyers ask about least.
If your app publishes under an agency’s Apple Developer or Google Play account, then the store listing, every rating and review accumulated, the install base and the ability to ship an update all belong to that agency. Ending the relationship means republishing under a new bundle identifier or package name, from zero reviews, with your existing users stranded on a version nobody can update.
The contract should say the accounts are registered to your company, the vendor is added with the access they need, and that access is removed at handover. On iOS, confirm who holds the signing certificates. On Android, confirm Play App Signing is enabled under your account rather than theirs.
Register them yourself before development starts. Our guides to the Apple Developer account and the Google Play Console cover the steps, including the D-U-N-S number an organisation account needs, which takes longer to obtain than anyone expects. The publishing cost breakdown covers the fees, and they are small enough that cost is never the real reason this gets skipped.
Ask this of every vendor you evaluate. The ones who answer cleanly and immediately have thought about it. The ones who get vague are telling you something.
Scope, Change Requests and What Fixed Price Means
The most common commercial dispute in this business, and the one least often written down properly.
“Fixed price” is only fixed against a fixed specification. Every agreement of this shape contains a change request mechanism, and the mechanism is where the money is. Read it before you sign, because you will use it, on every project, usually within the first six weeks.
Three things need to be explicit. What the baseline scope actually is, referenced to a document rather than to a conversation. How a change gets priced, at what rate, and whether you see an estimate before work starts. And who is allowed to approve one, because a developer accepting a request in a chat thread is how projects grow by 40 percent without anyone deciding to.
Insist that no change is chargeable without written approval in advance. Reputable firms want this as much as you do, since it protects them from doing unpaid work on a verbal ask.
Then be honest about which model suits you. Fixed price transfers risk to the vendor, who prices that risk into the quote and resists every change, which is the correct behaviour under that contract. Time and materials keeps you flexible and puts the overrun risk on you. Neither is better in general. Fixed price fits a well specified build, and time and materials fits a product still finding its shape, which is a distinction our MVP costing guide works through in more detail.
Watch for a scope document written in marketing language. “User management” is not a scope item, it is a category. If the specification cannot be turned into tickets without another round of conversation, it is not a specification and the change requests have already started.
Design deliverables get missed here more than anything else. Agree how many rounds of revision are included and what a round means, because UI and UX work is the easiest part of a project to iterate on forever, and it is frequently quoted as though it will be settled in one pass.
Acceptance, and What Counts as Done
If the contract does not define acceptance, then done means whatever the person who wants to invoice says it means.
Tie each milestone to an installable build rather than a status report. A build on TestFlight or a Play internal track is unambiguous. It either does the thing or it does not, and nobody has to interpret a percentage.
Give yourself a defined acceptance window, five to ten working days is normal, with the milestone deemed accepted if you say nothing. That last part is fair to the vendor and it protects you from your own delays, since a client who goes quiet for a month should not be freezing somebody’s cash flow.
Write acceptance criteria per milestone at the point the milestone is agreed, not afterwards. Three or four bullet points is enough. The exercise is worth it even if nobody ever refers back to them, because writing them down surfaces the assumptions each side was carrying.
Overlap Hours, Written as a Number
“Flexible working hours” and “we align with your timezone” mean nothing in a contract. India runs nine and a half to twelve and a half hours ahead of the United States depending on coast and season, so a vendor working standard Indian hours overlaps with US Eastern by approximately zero.
Ask for a committed number of overlap hours and what falls inside them. Standups, demos and decisions should. Then ask what happens when production breaks at 2am their time, and who you call. Incident response is a separate commitment from development hours, and if uptime matters it should be priced as an ongoing support arrangement with a stated response time rather than assumed into goodwill.
This is worth pushing on because it is the most common cause of slow offshore engagements. A question asked at 4pm in Chicago that gets answered the next afternoon turns a one day task into a week when it happens twice. Factor that into the project timeline rather than treating the estimate as though the team sat down the hall.
Termination, and What Arrives With It
Every agreement should say how either side exits and what you receive when you do.
Thirty days notice from either party is a reasonable norm. What matters more is what that period is spent on. A handover sprint should produce the repository with full commit history intact, credentials and environment documentation written for somebody who has never seen the project, open work written up as tickets, and ideally a recorded architecture walkthrough.
Ask the vendor what the last departing client actually received. A concrete answer means handover is a process. A vague one means it is an improvisation, and you will be the one improvising.
Also check whether anything is withheld pending final payment. Source code held hostage over an invoice dispute is a situation you want covered before it arises, not during.
One clause people forget in both directions. Non-solicitation, meaning neither side hires the other’s staff for some period after the engagement. Vendors ask for it and it is usually reasonable, since they carry the recruiting and training cost. What is not reasonable is a term running for years, or one broad enough to stop you hiring anyone who ever touched the project. Twelve months, limited to people who actually worked on your account, with a buy-out figure attached, is a normal shape. Worth negotiating if you might later want to bring the work in house.
Warranty, and What Counts as a Bug
Almost every agreement promises to fix bugs after delivery. Very few define a bug, which is where the argument happens.
The workable definition is that a bug is behaviour that does not match the agreed specification, and anything else is a change request. Sounds obvious. It stops being obvious the moment a screen works exactly as specified and the specification was wrong, which happens on every project.
Agree a warranty period, thirty to ninety days after acceptance is normal, during which defects are fixed at no cost. Then agree what falls outside it, because the interesting cases are all at the boundary. A crash on a device that was never in the agreed test matrix is a grey area worth settling in advance. So is a break caused by a third-party API changing underneath you, which is nobody’s fault and still somebody’s bill.
Two specific items to name explicitly, since both are common and both get billed as extras when they are not written down. First, store rejections: at a rejection rate of roughly one in four submissions, this is not a remote possibility, and fixing a guideline violation in the delivered app should sit inside the engagement. Second, a compliance release when Apple or Google raise their requirements, which happens annually and predictably.
Warranty is not maintenance and should not be sold as though it is. Warranty covers defects in what was delivered. Maintenance covers the app continuing to work in a changing world, which is a permanent cost rather than a period, and our maintenance cost guide covers what it actually runs to.
The W-8BEN-E and Getting Paid Properly
If you are a US company paying an Indian vendor, your finance team needs a completed W-8BEN-E on file. Without it, US rules require withholding 30 percent of every payment, and reclaiming that afterwards takes months of correspondence nobody enjoys.
A vendor who has genuinely worked with American clients has this ready before you ask. One who has not heard of it is learning on your engagement, which tells you something about their client base.
Agree the currency and the rails too. Invoicing in US dollars through international wire, ACH or Wise is standard. On fixed-scope work, tie milestones to demonstrable software rather than calendar dates, because dates pay out whether or not anything shipped.
Fix which side carries exchange rate movement while you are at it. Indian firms quote in dollars and book in rupees, so a rate held across a six month project can shift by several percent on currency alone. It is a two line clause and it prevents a conversation nobody wants to have in month five. Our breakdown of what it costs to hire in India covers the rate bands these payments sit against.
Confidentiality and Data Protection
A mutual NDA should be signed before the scoping call rather than after, since the scoping call is where you describe the product.
Beyond the NDA, ask where your production data actually sits during development. It should stay in your own cloud accounts under your credentials, with developer access granted per person and revoked at rollout. Vendors who take a copy of production data into their own environment for convenience are creating a risk you did not agree to.
If your product touches regulated data, the contract needs to reflect it. Health data in the US means a signed Business Associate Agreement under HIPAA, and most Indian agencies have never signed one, which our healthcare development guide covers alongside how the obligations differ between markets. European or Californian users bring GDPR and CCPA obligations that shape architecture rather than adding a checkbox. Payment data is best handled by keeping card details out of your app entirely so the PCI scope stays narrow, which is the first architectural decision on any fintech build.
India now has its own framework too. The Digital Personal Data Protection Act came into force in 2023, so an Indian vendor has domestic obligations of its own. That is a genuine improvement on the previous position and it discharges none of yours, since you remain the controller in the eyes of whichever regulator covers your users.
Then ask who carries liability if there is a breach. Many offshore agreements cap vendor liability at the fees paid, which for a small engagement is close to nothing. That may be acceptable. It should be a decision rather than a discovery.
A Checklist You Can Take to Any Vendor
Ask these six, ask for the answers in writing, and ask us the same questions.
- Does IP assign to us at each invoice, on work-for-hire terms, with no broad background carve-out?
- Will the repository sit in our organization from the first commit?
- Will the app publish under our Apple and Google accounts, with signing keys in our control?
- How many hours a day will we overlap, and who do we call outside them?
- On thirty days notice, what exactly do we receive, and is anything withheld?
- Can you supply a W-8BEN-E before the first invoice?
A vendor who answers all six crisply has done this before. One who treats the questions as unusual has not, and you would be their education.
Frequently Asked Questions
Do we need a lawyer to review an offshore development contract?
For anything beyond a small fixed-scope build, yes, and specifically someone who has seen cross-border technology agreements. The cost is small relative to a dispute over code ownership.
Is a US or Indian governing law clause better for us?
Most US clients prefer their own jurisdiction and most Indian vendors accept it. What matters more in practice is that the commercial terms are clear enough that you never test the clause, because cross-border litigation is impractical either way at typical project values.
Should we pay a deposit up front?
An initial milestone payment is normal, usually 20 to 30 percent. What is not normal is paying a large share before any code exists. Milestones tied to installable builds protect both sides better than a calendar schedule does. Our breakdown of app development costs in India covers what a full build runs to, which is the figure any deposit should be judged against rather than against the deposit sounding reasonable on its own.
What if the vendor wants to use their own contract template?
That is fine and usually faster. Read it against the six questions above and negotiate the gaps. Vendor templates tend to be silent on store account ownership and light on termination, which are precisely the items you care about.
Does any of this change if we hire a dedicated developer rather than a fixed-scope build?
The IP, store account and data clauses stay the same. What changes is that you add a replacement obligation with a deadline attached, and notice periods matter more because you are relying on continuity of one person. Scope and acceptance matter less, because you are buying time rather than an outcome.
How long should the whole agreement be?
Shorter than you would think. Most of what matters here fits in ten to fifteen pages. A sixty page agreement is usually a template nobody has read, and length correlates with nothing useful. What matters is whether the six questions are answered, not the word count.
Can we start without a contract and formalise it later?
People do, and it works until it doesn’t. If you are going to, at minimum sign an NDA and get the repository and store accounts in your name before any code is written. Those two things are most of the protection, and they cost nothing to arrange. The rest can follow a pilot, which our development process guide covers in sequence.
Getting the Commercial Side Right
If you are still working out which arrangement suits you, our hire app developers in India guide covers dedicated hiring against fixed-scope delivery and the red flags in each, and the stack-specific pages for React Native, Android and iOS cover what those engagements look like in practice.
For the process of finding and screening people, how to hire app developers in India walks through it step by step, and interview questions for mobile app developers covers the technical screening once you have candidates in front of you.
Everything above is how we work by default, which is easy to claim on our own site, so ask us the six questions and check the answers against the work we have shipped. If you have a draft agreement from somebody else and want a second read on it, send it over.
