Contracts, IP assignment, a time-zone playbook, security questionnaires and a vendor checklist for US companies hiring an Indian development partner.
In this article
- 01Why US companies outsource to India, and where it goes wrong
- 02Contracts: what the MSA and SOW should say
- 03IP assignment that holds up in both countries
- 04A time-zone playbook for US teams
- 05Security expectations: SOC 2 questionnaires and beyond
- 06How to evaluate an Indian vendor
- 07Common mistakes US teams make
- 08Payments, taxes and paperwork
- 09Start small, then scale
Why US companies outsource to India, and where it goes wrong
US startups and product teams work with Indian development partners for three main reasons: access to experienced engineers without a long hiring cycle, a cost structure that stretches a seed or Series A budget further, and the option of progress happening overnight. India has a deep pool of engineers across mobile, web, cloud and AI, and English is the default working language in the industry.
When these engagements fail, the cause is rarely technical skill. It is usually a vague scope, a contract that never actually transferred the IP, unclear ownership of cloud and app store accounts, or a communication rhythm that left both sides waiting a day for every answer. This guide covers how to avoid each of those problems.
Contracts: what the MSA and SOW should say
Most US companies use a master services agreement (MSA) for the legal terms and a statement of work (SOW) for each project or phase. Keep the MSA stable and let SOWs change as the product evolves. Whatever template you use, make sure these points are covered in writing:
- Scope, deliverables and acceptance criteria for each milestone
- Engagement model: fixed price, time and material or a dedicated team
- Payment terms, currency and what happens to unpaid or disputed invoices
- Confidentiality, data protection duties and security requirements
- Warranty period for defects after acceptance
- Governing law, dispute resolution and, often, arbitration at a neutral seat
- Termination rights and a handover obligation covering code, credentials and documentation
IP assignment that holds up in both countries
Do not rely on the US work-for-hire doctrine. It fits employees and a narrow list of commissioned works, and it does not reliably cover software written by a foreign company. Instead, the contract should contain an express assignment, worded as a present transfer ("hereby assigns"), of all rights in code, designs and documentation created for you.
Indian copyright law adds a practical wrinkle. An assignment that does not state its duration or territory can be read narrowly, by default as five years and limited to India. The clause should therefore say the assignment is worldwide and for the full term of the rights. Also ask the vendor to confirm that its own employees and subcontractors have assigned their work to it, so the chain of title is complete.
Expect the vendor to keep ownership of pre-existing tools and libraries and grant you a perpetual license to use them in your product. Ask for a list of open source dependencies and their licenses before launch. This section is general information, not legal advice, so have your counsel review the final wording.
A time-zone playbook for US teams
India Standard Time is UTC+5:30 with no daylight saving. New York is 9.5 hours behind India in summer and 10.5 hours in winter; San Francisco is 12.5 and 13.5 hours behind. That gap is a feature if you plan for it: work you hand off at the end of your day is done while you sleep.
East Coast teams usually hold a stand-up in their early morning, which is the Indian evening. West Coast teams often prefer their late afternoon, which is early morning in India. Either way, these habits keep the gap productive:
- One fixed overlap window of about an hour, every working day
- Written end-of-day updates from the Indian team, with links to builds
- Tickets written with acceptance criteria, so nothing waits for clarification
- A named point of contact on each side with authority to decide
- Staging builds you can test asynchronously, not only in demos
Security expectations: SOC 2 questionnaires and beyond
If you sell to enterprises, your customers will ask how your vendors handle their data, and you will likely send your offshore partner a security questionnaire such as SIG Lite or the Cloud Security Alliance CAIQ, or simply a list of SOC 2 control questions. Many small and mid-sized Indian firms do not hold a SOC 2 report of their own, so ask what they can evidence instead: written policies, access reviews, device management and incident procedures.
In practice the strongest controls are structural. Keep source code, cloud accounts, app store accounts and production databases under your own organization and grant the vendor role-based access with multi-factor authentication. Keep production personal data out of development environments. If the product handles protected health information, you will need a business associate agreement under HIPAA before any PHI is shared.
How to evaluate an Indian vendor
Rankings and award badges tell you little. Evidence tells you a lot. Before signing, work through this list:
- Live products you can install or log into, similar in complexity to yours
- Two or three client references you can speak with directly
- The names and roles of the people who will actually work on your project
- A written plan with milestones, assumptions and what is out of scope
- A sample of their code, pull request reviews and test coverage
- How they handle scope changes, bugs after launch and team turnover
- Company registration and a physical office you could visit
Common mistakes US teams make
Most failed offshore projects share a few avoidable mistakes. They are rarely about the vendor's location and almost always about how the engagement was set up. Watch for these in your own planning:
If nobody on your team can review code, consider a part-time technical advisor or a virtual CTO for the first months. An independent reviewer catches problems early and gives you someone to ask when an estimate looks wrong.
- Handing over a one-page idea and expecting a fixed price that holds
- Letting the vendor open cloud, app store or domain accounts in its own name
- Skipping code review because nobody on the US side reads code
- Treating the stand-up as optional, so small questions wait a full day
- Measuring progress by hours billed instead of working features shipped
Payments, taxes and paperwork
Payments to an Indian vendor normally go by international wire, usually in USD, against invoices tied to milestones or monthly team billing. Your finance team will typically ask a foreign vendor for Form W-8BEN-E instead of a W-9, and a foreign company does not receive a 1099. Tax treatment depends on your situation, so confirm details with your accountant.
Choosing the engagement model matters as much as choosing the vendor. Fixed price suits a well-defined MVP; time and material suits evolving products. Our comparison of fixed price vs time and material explains the trade-offs, and in-house vs outsourcing helps decide what to keep internal.
Start small, then scale
The lowest-risk way to start is a paid discovery phase or a short first milestone with a clear deliverable. You see how the team writes, estimates, communicates and handles feedback before committing to a larger budget. If that goes well, scale into a dedicated development team.
Nexzem Technologies is a software development company based in Dehradun, India. We have no US office; we work with US clients remotely, with planned overlap for East and West Coast teams. Our page for US companies explains how we structure contracts, hours and IP transfer.



