Setting Up an Offshore Development Center: Lessons from a Decade in India

ByVRISols

When we started building offshore teams for global software vendors back in 1995, the typical engagement was a fixed-price project shipped to India, completed, and handed back. A decade on, that model is giving way to something more strategic for ISVs: the dedicated offshore development center, or ODC.

This post pulls together what we have learned from running these centers for independent software vendors in the US and UK across multiple product domains. Most of it is unglamorous. All of it matters.

Why ISVs are moving away from project-based work

Project engagements made sense when the goal was a one-time deliverable. They no longer fit how product companies actually build software. Three reasons keep coming up in conversations with CTOs:

  1. Product roadmaps run for years, not quarters. Rebidding every release destroys domain knowledge that took months to build.
  2. Engineering needs continuity of people, not just continuity of contracts. ISVs want the same architect who designed the persistence layer available eighteen months later when it needs rework.
  3. Total cost of ownership is lower when ramp-up costs are amortized across a long horizon. Project pricing hides this. ODC pricing makes it visible.

The shift is clear. CTOs are buying capacity and capability, not deliverables.

The three setup options

There is no single right model. We see three structures in active use today.

Full captive. The ISV incorporates an Indian subsidiary, hires directly, and runs the center as its own. Best suited to firms with more than fifty offshore engineers, deep IP concerns, and the appetite for managing Indian HR, payroll, statutory compliance, and real estate. Expect six to nine months before the first engineer writes a line of code.

Partner-operated. A local services firm hires the team, provides infrastructure, handles compliance, and bills the ISV on a transparent cost-plus or per-seat basis. The team is dedicated, badged to the client, and works only on client product. Setup time is typically four to eight weeks. This is the most common starting point for firms under fifty offshore heads.

Hybrid, also called build-operate-transfer. The partner sets up and runs the center for a defined period, usually two to three years, after which ownership transfers to the ISV. Useful when the ISV wants the captive endgame but does not want the cold-start risk. Contract design matters more here than in either pure model.

Infrastructure essentials

Connectivity is where most setups stumble. Plan for the following:

  1. A primary international private leased circuit, typically an IPLC, sized for development traffic plus video conferencing. Two megabits per second is a reasonable floor for a thirty-person center.
  2. A redundant link from a different provider on a different physical path. Same-provider redundancy is not redundancy.
  3. ISDN backup for voice and emergency data. Submarine cable cuts still happen and the recovery window is measured in days, not hours.
  4. A site-to-site VPN terminating at the client network.
  5. Power backup sized for at least four hours of full operation. Diesel generator plus UPS is standard.

Office space in Bangalore, Hyderabad, Chennai, or Pune within an STPI-approved facility simplifies tax treatment and customs handling for imported hardware.

Knowledge transfer is longer than you think

For a medium complexity product, plan eight to twelve weeks of knowledge transfer before expecting meaningful output. We have seen ISVs budget two weeks and then spend the next six months wondering why output is poor. A proper transfer includes:

  1. Two weeks of onsite immersion for the lead architect and two senior engineers at the client location.
  2. Recorded walkthroughs of the codebase, build system, and release process.
  3. Shadow assignments where offshore engineers pair with onshore counterparts on real tickets.
  4. A documented exit criterion for KT. Not a date, but a checklist of demonstrated competencies.

Compressing this window is the single most common mistake we see.

The team pyramid that works

For a steady-state ODC handling product engineering, the shape we recommend is:

  1. 1 architect
  2. 2 senior engineers
  3. 4 mid-level engineers
  4. 3 junior engineers

That ratio holds for teams of about ten. Scale it in multiples, not by adding juniors at the bottom. Junior-heavy teams produce code that senior engineers spend their time fixing, which defeats the cost rationale that brought the ISV offshore in the first place.

Five governance practices we recommend from day one

  1. A single point of accountability offshore. One delivery manager owns outcomes. Not a committee, not a shared role.
  2. Weekly status with metrics, not narratives. Defect counts, build health, story completion. Reports without numbers drift into reassurance.
  3. Quarterly business reviews with the ISV leadership. Surface concerns before they become resignations.
  4. Defined escalation paths. Engineer to lead, lead to manager, manager to client sponsor. Documented and rehearsed.
  5. An attrition early warning system. Skip-level conversations, salary benchmarking twice a year, and retention bonuses tied to product milestones. Attrition in Indian IT is running between fifteen and twenty-five percent. Plan for it rather than hope it skips your team.

Closing thought

An ODC is not a discount engineering team. It is a long-term capability that compounds if you treat it as one. The ISVs that get the most from offshore are the ones that invest in governance and continuity from the first week, not the ones who try to retrofit it after the second resignation letter lands on the manager’s desk.