Quick look:
| To set up an offshore development center in India, decide what work the team will own, choose a vendor that can staff it, and agree the contract before anyone is hired. Interview every engineer yourself, keep daily direction with your own engineering lead, and write IP, security, and exit terms into the agreement from the start. If the team will become core to your product, plan the move to owning it at signing, because that is when the terms are easiest to agree. |
An offshore development center is a team in India that works only for you, while a vendor employs, houses, and manages it. Setting one up takes four decisions: the work, the vendor, the contract, and who runs the team day to day. Get those right and an ODC can be working within weeks, without an entity of your own.
This guide is for CTOs, founders, and engineering leaders at growth-stage companies setting up a dedicated team in India through a vendor. It walks through the setup in order and ends with the cases where owning the team is the better route.
What is an offshore development center?
An ODC is a dedicated team that a vendor employs for one client. The engineers work only on your product, from the vendor's office, on its payroll, and under its HR policies.
It differs from a global capability center in two ways. The first is who the team reports to, and the second is who owns the entity that employs it.
Our comparison of GCC and ODC models covers that difference in full. This guide assumes you have chosen the ODC route.
That route suits work that is clearly defined, has an end date, or is useful without being central to your product. It also suits a company that has no plans to run an entity in India.
1. Decide what the team will own
Start with the work, not the vendor. Write down the product area, service, or project the team will take on, and what done looks like for it.
Then describe the first team by role, not just by size. A backend team of 5 needs a senior lead, 3 engineers, and a tester, and each role has a different hiring bar. Vendors staff to the brief they are given, so a vague brief produces a team that does not fit the work.
Decide how long the work will run, too. The answer shapes the contract term, the exit terms, and whether an ODC is the right model at all.
2. Choose the city and the vendor
The vendor's location decides the talent market your team is hired from. Bengaluru, Hyderabad, and Pune each have deep engineering markets with different strengths, and our India location guide compares them.
Shortlist vendors on how they hire, because that decides the quality of the team you get. Ask three things:
- Where do candidates come from before a role exists?
- Who vets each candidate, and has that person done the job?
- What happens when an engineer leaves in the first few months?
Our guide to choosing a GCC partner covers the full evaluation, and the same checks apply to ODC vendors.
3. Agree the commercial model
ODC vendors usually charge a monthly rate for each person on the team. The rate covers employment, payroll, workspace, and the vendor's management, and it may or may not include devices, software licenses, and recruitment.
Get the inclusions and exclusions in writing before you compare rates. Two vendors with similar rates can cost very different amounts once the extras are added. Our guide to GCC partner pricing explains how to compare proposals that are priced differently.
Ask how the rate changes over time, too. Annual salary increases, promotions, and replacements can all change it, and each should be agreed in advance.
4. Interview every engineer yourself
A dedicated team only works if you choose the people on it. Insist on approving every engineer before they join, and run your own technical interview for each one.
Watch for two warning signs. The first is a vendor that offers engineers it already has on staff but has not placed, before it searches for your roles. The second is an engineer who is shared with another client, which defeats the point of a dedicated team.
Your interview should test the work the team will actually do. A take-home exercise or a pairing session on code from your own repository shows more than questions about a CV.
Hire the team lead first. That person sets the standard for every hire after them, so the lead's interview deserves the most time. Notice periods in India can be long, so plan start dates around them rather than around the contract date.
5. Keep daily direction with your team
The ODC's engineers take their daily priorities from your engineering lead, not from the vendor's project manager. The vendor runs employment and the office, while you run the work.
That split needs to be written into the contract and into the team's weekly routine. Agree a daily written handoff, a weekly live sync inside the overlap hours, and a monthly review with the vendor. Our guide to managing an India team covers the time difference and the habits that keep a remote team aligned.

6. Set the security and IP terms
The ODC's engineers will work on your code and often your customer data, so your security baseline should apply to their devices and accounts. Ask the vendor to manage access through your single sign-on and keep an asset register for every laptop. Each device is wiped or returned the day someone leaves.
Ownership of the IP needs an unbroken chain. Each engineer's employment agreement assigns their work to the vendor, and the vendor's contract with you assigns it on to your company. Check both links, because a gap in either leaves your code in the vendor's hands.
India's data protection law also applies to personal data the team handles. Our GCC compliance guide covers what the DPDP Act asks for.
7. Write the exit in at signing
Every ODC contract should say how it ends. Exit terms are easiest to agree before the team becomes hard to lose, and hardest afterward.
The clauses below are the ones that decide what you keep when the arrangement ends:
| Clause |
What to ask for |
| Notice period |
A period long enough to hand over the work without disruption |
| Transfer of the team |
The right to move engineers to your own entity on agreed terms |
| Conversion fee |
A fixed, written figure for moving each engineer, or none |
| Non-solicitation |
Terms that do not block hiring the team when the contract ends |
| Knowledge transfer |
Documentation and handover duties during the notice period |
| IP and data |
Confirmation that all code, documents, and data return to you |
A transfer clause matters most if the team might become core to your product. Without it, the people who know your code stay with the vendor when the contract ends.
8. Start with one product area, then grow
Launch the ODC on one product area with a clear boundary. An area tangled up with other systems gives the new team its hardest problem on day one. A well-bounded area lets it ship early and earn the next piece of work.
Add people in steps once the first team is working. Tie each step to a review of what the team has shipped.
Measure the ODC the way you measure any team. Delivery against the roadmap, quality in production, and retention by quarter tell you whether it is working. Hours logged and response times tell you very little across a time difference.
How long an ODC takes to start
An ODC starts faster than an owned center, because the vendor already has an entity, an office, and payroll in place. The time goes into finding the right people.
Plan for four stages. Choosing the vendor and agreeing to the contract comes first, then the search and your interviews, then notice periods, and finally onboarding. The notice period is usually the longest of the four, and it is the one you cannot shorten.
The team lead's start date sets the pace for everything after it. If the lead joins late, the first engineers start without the person who should be setting their standard.

When to own the team instead
An ODC is the wrong fit for a team you will depend on for years. If losing the team at the end of the contract would slow your roadmap, plan to own it from the start.
Owning the team does not mean waiting for an entity. With InCommon, Podifi had 9 engineers live in 6 weeks, employed through employer of record with no wait for incorporation. For Accompany Health, the result was 22 people, 10 weeks to a live team, and 100% retention across the build.
Our guide to setting up a GCC walks through the owned route step by step. To talk through which model fits your plans, our India ODC page explains our approach.
If owning the team is the better route for you, this is where to start.
Everything you need to build and run your India GCC.
Entity, hiring, workspace and ongoing operations under one agreement.
Final thoughts
An ODC is quick to start and simple to run. It works when you choose the people, keep the direction, and settle the exit at signing. When an ODC disappoints, the cause is usually one of those three rather than the vendor's rate.
Decide at the start how long you expect to need the team. The answer tells you whether an ODC or an owned center is the right place to begin.