The reason CTOs build offshore development centres changed, and most of the content written about them has not caught up.
Deloitte put the question to more than five hundred executives in its 2024 Global Outsourcing Survey and found that cost, which was the primary driver for 70% of them in 2020, had fallen to 34%. What replaced it was control and capability. In the same research, seven in ten organisations said they had pulled previously outsourced work back in-house over the preceding five years, and when asked why, tighter quality control came in at 68% and rebuilding internal expertise at 64%.
An offshore development centre is what that shift looks like in practice. It is not a vendor relationship with better branding. It is a company deciding to own an engineering capability abroad rather than rent hours from someone who owns it instead.
The same survey found 78% of firms already operating a captive centre of some kind, with nearly three-quarters planning to expand. So the question for most CTOs is no longer whether to do this. It is which structure to do it through, and that decision is harder than it looks.
What an offshore development centre actually is
An ODC is a dedicated engineering operation in another country, working exclusively for one company, integrated into its processes and directed by its engineering leadership.
The word doing the work in that sentence is dedicated. A software development agency assigns engineers across many clients and reallocates them as projects come and go. An ODC does not. The engineers are yours, the roadmap is yours, and the team persists.
You will also see this called a Global Capability Centre, particularly in India, where the term has largely replaced the older captive centre language. The distinction between GCC and ODC is mostly one of scope and ambition rather than structure: GCCs tend to describe larger operations spanning multiple functions, ODCs describe engineering specifically. In practice the setup decisions are the same.
Choosing the operating model, which is the decision everything else follows from
There are three real options and the trade-off between them is speed against control.
Setting up a wholly owned subsidiary gives absolute legal control and direct ownership of everything. It also means incorporating a foreign entity, navigating local employment law, registering for tax, securing premises, and building an HR and compliance function before a single engineer writes code. The capital and calendar cost is substantial, and I have watched companies underestimate the calendar part more than the capital part. Twelve to eighteen months from decision to a productive team is realistic for a subsidiary built from scratch.
A partner-operated model puts a local specialist in the employer position. They hold the entity, run recruitment, employment, payroll, infrastructure, and compliance. The company keeps hiring decisions, technical direction, and day to day management of the work. Speed to a working team is measured in months rather than years, and the capital outlay is close to nil.
Build-Operate-Transfer sits between them, and it is where the market is moving. A partner stands the operation up and runs it, with a contractual path for the company to absorb the entity, the team, and the infrastructure later. Deloitte's data shows roughly half of organisations adopting captive centres favour a Build-Operate-Transform-Transfer structure, which is the same instinct as the repatriation numbers: companies want the capability inside the organisation eventually, without carrying the risk of building it cold.
Transfer windows are usually negotiated somewhere between eighteen months and three years. I would treat any specific figure in an article, including that one, as a convention rather than a rule, and negotiate it against the actual roadmap.
The legal and compliance questions worth settling in writing
This is the section most guides skim and it is where the expensive surprises live.
Who legally employs the engineers. A properly constituted local entity with real employment contracts, or a chain of contractors. This matters far beyond tidiness, because intellectual property assignment flows through the employment relationship. If the employment structure is thin, the IP assignment sitting on top of it may not hold when tested.
Who owns the code. The answer should be the client, in full, from the first day, with no licensing clause and no fee attached on exit. I would read this in the contract rather than accept it in a meeting, because the qualification is often several pages further in than anyone reads.
Where data can sit and where it can travel. Residency obligations under GDPR or sector-specific regulation, and what the arrangement does about them.
What happens at the end. Notice terms, and specifically whether the intellectual property or the team transfers cleanly. For a BOT arrangement, the transfer mechanics deserve as much attention at signing as the operating terms, because that is the part nobody negotiates hard when the relationship is new and everyone is optimistic.
Scaling the team without breaking the team
The most common way I see an ODC go wrong is not a bad hire. It is hiring too many good ones at once.
Every new engineer consumes senior capacity during onboarding, and that capacity comes out of the same people who are shipping. Add four engineers to a team of six and delivery slows before it accelerates, sometimes for a whole quarter, and the company concludes the model does not work when what actually happened was an onboarding bottleneck of its own making.
I do not have a defensible universal ratio to offer, and I would be sceptical of any article that gives one, because the right pace depends entirely on codebase complexity, documentation quality, and how much of the senior team's week is already committed. What I would do instead is treat onboarding capacity as an explicit constraint in the hiring plan, name who owns it, and protect their time in the sprint rather than assuming it is free.
The related discipline is sequencing. The first hires into an ODC should be senior. Not because juniors cannot contribute, but because the early team sets the architectural direction and the working norms that everyone joining later inherits, and correcting either one afterwards is expensive.
Integration, which is not the same as communication tooling
Most ODC integration advice reduces to a list of tools and an overlap window. Both matter and neither is the point.
The principle is that whatever the internal team gets, the offshore team gets. The same CI pipeline with the same gates. The same code review standards applied in both directions. The same sprint ceremonies rather than a parallel set. The same access controls, applied on role rather than on geography, because differentiating by location adds friction and communicates distrust without improving security in any way that survives examination.
Three to four hours of daily overlap is what I would target, used for planning, architectural discussion, and unblocking, with everything else running asynchronously. And a decision made in a call needs to exist in writing before the day ends, or the offshore team arrives to a codebase that changed direction overnight for reasons nobody recorded.
Documentation is the real dependency here and it gets treated as housekeeping. An engineer eight hours away cannot lean over and ask. Every undocumented architectural decision becomes a blocked day.
How we do it
We are not an agency and we are not a consultancy. We do not sell projects and we do not resell hours.
We build and run a dedicated engineering operation in Bangalore for one partner at a time. Recruitment, employment on proper local contracts through our own Indian entity, infrastructure, workspace, retention, and the operational care of the team sit with us. Hiring decisions, technical direction, priorities, and standards sit with our partner.
Every line of code, every architectural decision, every piece of documentation that team produces is our partner's intellectual property, in full, from day one. No licensing clause, no shared ownership, nothing owed on it if the engagement ends. Where a partner wants to take the operation over entirely, build-operate-transfer is a route we support, and the transfer terms are negotiated at the start rather than improvised later.
Bangalore matters for this specifically because an ODC only works if the senior pool is deep enough to recruit against continuously rather than opportunistically. The city has been building at cloud scale for two decades, which is why a search for a senior engineer there is a predictable process rather than a hopeful one.
Where we are not the right answer: a company that needs three engineers for four months, or one with clearance requirements no offshore structure can satisfy.
Questions CTOs ask
What is an offshore development centre?
A dedicated engineering operation in another country working exclusively for one company, integrated into its processes and directed by its engineering leadership, as distinct from an agency that allocates engineers across many clients.
What does ODC setup involve?
Choosing an operating model, establishing or renting a legal employment structure, recruiting, provisioning infrastructure and access, and integrating the team into existing engineering processes. The model choice determines how much of that the company does itself.
What is the difference between an ODC and BOT?
An ODC describes what the operation is. Build-Operate-Transfer describes how ownership moves. A partner-operated ODC with a transfer clause is a BOT arrangement, so the two are not alternatives so much as different dimensions of the same decision.
How long does it take to set up?
Months for a partner-operated model, considerably longer for a wholly owned subsidiary built from scratch, where entity formation and compliance run before any hiring begins.
Who owns the intellectual property?
In our model, the partner does, completely and from day one. This varies genuinely across providers and structures, and it is the single term I would read most carefully in any agreement.
What I would tell a CTO deciding this week
The model choice is really a question about permanence and appetite for operational work.
A company certain this capability is permanent, with the capital and the patience for entity formation, should probably own the subsidiary. A company that needs the capability working this year should use a partner-operated model. A company that wants both should structure it as build-operate-transfer and negotiate the transfer terms while the relationship is new, because that is the only point at which anyone has leverage to get them right.
What I would not do is let the cost comparison drive it. Deloitte's own numbers show cost falling from the primary consideration for seven executives in ten to roughly one in three, and the organisations still optimising purely for rate are well represented among the 70% who ended up pulling the work back in-house
Top comments (0)