The questions US companies actually ask before building a capability centre in India, answered directly. Where the honest answer is that it depends, we say what it depends on.

Five sections: the model itself, cost, timelines and setup, people and hiring, and legal, IP and compliance.
These are the questions that come up in first conversations, answered as directly as we can. Where an answer genuinely depends on your situation we say what it depends on rather than giving a number that would be wrong for most readers.
Anything on this page describing the wider market is our reading of it rather than a research finding. Where we cite external research elsewhere on this site, we link to the source.
A global capability centre is an offshore entity owned by the parent company that holds capability the business depends on: engineering, data, platform, support or back office functions run as a permanent part of the organisation rather than contracted from a vendor. The defining characteristic is ownership. The company employs the people, holds the knowledge and is accountable for outcomes rather than for hours billed.
A Nano GCC is a small capability centre, typically ten to two hundred people, deliberately weighted toward senior staff and scoped around owning specific outcomes rather than absorbing volumes of specified work. The difference from a traditional GCC is not only size. A traditional centre was built to scale; a Nano GCC is built so that a small number of people can own something end to end and decide about it locally.
In outsourcing, the engineers are employed by a vendor, the vendor holds the accumulated knowledge, and the arrangement ends when the contract does. In a capability centre the engineers are your employees inside your own entity, the systems and IP are yours outright, and the context stays with your company. Outsourcing buys capacity; a capability centre builds capability.
No, and the distinction is structural rather than cosmetic. Staffing gives you people who work for someone else, can be reassigned, and take their understanding with them. A Nano GCC gives you an owned entity, your own employees, a short and uncontested IP chain, and a team that can be given genuine decision authority because it answers to you.
When the work is genuinely temporary and will end, when you need output within six weeks, when no executive sponsor will protect the centre through a difficult quarter, or when the real constraint is prioritisation rather than capacity. In the last case an offshore team will scale the existing problem rather than solve it.
No, and this is the change most companies have not revisited. The old threshold of several hundred people existed because entity, compliance and infrastructure costs had to be spread across a large headcount. Those costs have fallen far enough that a team of eight to fifteen is viable, which puts the model within reach of companies for which it was previously impossible.
Rather than quoting a rate, model it fully loaded on both sides. Most published comparisons compare US base salary against fully loaded Indian cost, which is not a like for like comparison and understates the real difference. A complete model includes salary and statutory costs, entity and compliance, workspace and infrastructure, recruitment, ramp, attrition, travel and onshore management overhead.
Onshore management overhead and knowledge transfer drag. Neither appears on an invoice because both are consumed time rather than spend, and both land in a different budget from the one being scrutinised. They are also at their highest in the first year, which is exactly when the business case is being validated.
Yes, for two deliberate reasons. Fixed costs such as entity, compliance and audit cannot be spread across a large headcount, and the seniority mix is heavier by design. The relevant measure is cost per delivered outcome, where a small senior team usually performs better because it consumes far less supervision and reworks less.
Faster than most expect for a small centre, because there is no facility build or multi year hiring programme on the critical path. First productive output at three to four months, with the full team contributing by around month six. The deepest point of the curve is the first quarter, when fixed costs are incurred against zero output.
Usually yes, and the saving is real even after every hidden cost is included. The risk is not that a centre is uneconomic; it is that it was approved on a number that was never achievable, and then judged against it in year two. A smaller number you can defend is worth more than a larger one you will spend a year explaining.
Three to four months from decision to first productive output for a small team. The traditional twelve to eighteen month timeline was mostly an artefact of doing the work sequentially. Entity formation, compliance registration, infrastructure and the senior search have very few genuine dependencies and can run in parallel.
The senior pod lead hire. Every subsequent hire depends on that decision, and no amount of parallelism elsewhere compensates for opening the search late. Starting it in week six rather than week one is the single most common cause of a slipped launch.
Four things, and three are within your control: starting the senior search late, provisioning access and environments only after people arrive, leaving the decision boundary undefined, and having no named transfer date. Statutory processing time is genuinely fixed and is rarely the binding constraint.
First production changes around week ten to sixteen, and ownership of a named system between month four and six. Measuring delivery output before week ten produces activity theatre and teaches the team to optimise for looking busy rather than for becoming capable.
Rarely, and treating workspace as a precondition is one of the assumptions that made the traditional timeline long. It is a decision that can follow the team rather than precede it, and it should never sit on the critical path.
It follows from what you want owned rather than from a headcount target. Eight to twelve is the practical floor for a team that owns a system end to end. Ten to forty is typical for a product engineering mandate. Above that, the question is usually whether it should be several teams with separate ownership rather than one large one.
Heavier than intuition suggests, and it runs opposite to how offshore cost models are usually built. A team of six to eight typically needs around sixty percent at senior or lead level; a team of thirty can work closer to thirty five percent. A small team has no ambient context to absorb, so judgement has to be present in the headcount.
Yes, and it is the main argument for the location. What determines whether you can is role design rather than market supply. Senior candidates in India assess a role on what they will own and what they can decide, exactly as they would anywhere. A support role scoped as offshore capacity will not attract them at any salary.
Treat it as a scope question rather than a compensation one. Senior engineers leave when the work stops being interesting, which usually means ownership was withdrawn or scope narrowed. Track regretted attrition among senior engineers separately from total attrition, because the two mix very different events.
Two to three hours a day is sufficient when the team has genuine decision authority. If a team needs four or more hours of overlap to function, that is evidence the decision boundary is drawn too tightly rather than evidence you need more overlap.
The team lead should have one solid line into engineering leadership rather than into a regional operations function, with dotted lines named explicitly. Genuine dual reporting fails across a time zone gap, because it resolves into whichever instruction arrived most recently.
You do, in an owned entity arrangement. The engineers are employees of your Indian subsidiary, their employment contracts assign work product to that entity, and an executed intercompany agreement assigns it onward to the parent. This is a short chain with no third party whose commercial interests differ from yours. Take qualified counsel in both jurisdictions on your specific arrangement.
In an owned entity the engineers are your employees under your own access control policy, background check standard and offboarding process, and there is no additional third party processor to document or assess. The control environment should be designed alongside the entity rather than retrofitted after the first assessment.
Yes. Entity formation, statutory registration, payroll, benefits, statutory filings and the annual compliance calendar are handled end to end. That is the practical difference between a capability centre and a set of vendor relationships you have to coordinate yourself.
An Indian entity carries recurring obligations including statutory filings, annual audit, tax compliance and employment law requirements. They are predictable and well trodden rather than onerous, but they are permanent and they are a fixed cost that does not scale down, which matters most for small centres.
A small team with reasonable notice periods, no facility commitment and no capital expenditure is a genuinely bounded commitment, and winding down an entity is a defined process rather than an open ended one. We model the exit cost before you commit, because a commitment you cannot unwind is not one you should make.
If you are weighing this decision, the fastest route is a direct conversation. We will tell you if the model does not fit your situation.