Why Nano GCCs Are Replacing Traditional GCC Models
For twenty years, the answer to “should we build a capability center in India” was effectively the same regardless of who asked it. Build big, plan for a year, and expect to employ several hundred people before the economics work. That answer was not lazy. It reflected a genuine constraint.
That constraint has now been removed, and the market is reorganising around its absence. Roughly a third of India’s capability center ecosystem is now made up of small, mandate-specific centers rather than large captive operations. This is not a fashion. It is what happens when a fixed cost that used to require scale stops requiring it.
This article explains the mechanics of that shift, why it happened when it did, and what it changes for a company weighing the decision today.
Key takeaways
- Traditional GCCs were large because fixed overhead, entity, compliance, facilities, HR, only amortised at scale.
- Partner-operated models spread that overhead across many clients, so a 15 person team can access it without providing the scale.
- AI and modern tooling independently reduced the headcount a given mandate needs.
- Speed became a competitive variable: a quarter versus a year is now a real strategic gap.
- The traditional model is not obsolete. It is now one option among several rather than the only route.
The constraint that shaped the old model
To understand why the model is changing, it helps to be precise about what forced its original shape. It was not a belief that bigger teams work better. It was arithmetic.
An Indian legal entity has to be incorporated and maintained. Statutory compliance has to be administered continuously. Payroll, benefits and insurance need an HR function. Grade A office space carries a lease. Secure infrastructure and IT support have to exist. Each of these has a floor cost that does not scale down: it costs roughly the same whether the center employs forty people or four hundred.
Spread that floor across four hundred people and it disappears into the per-head economics. Spread it across forty and it dominates them. That single fact is why capability centers were historically available only to companies large enough to provide the denominator.
What actually removed the constraint
Two independent developments, arriving at roughly the same time, dismantled the arithmetic.
Partners began carrying the fixed layer
Operators emerged that run the entity, compliance, payroll and facilities across many clients at once. The overhead still exists, but it is amortised across a portfolio rather than requiring any single client to supply the scale. A fifteen person team now reaches enterprise-grade infrastructure without enterprise-grade headcount.
AI reduced the headcount a mandate needs
Agentic tooling and modern engineering practice mean a small senior team can credibly own scope that previously required a much larger one. The teams companies actually need got smaller at the same moment small teams became economically viable.
These two changes compound. Each alone would have made small centers somewhat more feasible. Together they made them the default shape for a specific and very common requirement: one capability, owned properly, live soon.
Why speed became the deciding variable
Cost dominated the first two decades of this conversation because cost was the only variable that clearly differed. When every option took a year to stand up, timeline was a constant and therefore not a differentiator.
Once one option delivered a working team in three to four months while another took nine to eighteen, timeline became the sharpest difference between them. And unlike a rate differential, a timeline difference compounds: a capability live two or three quarters earlier affects everything downstream of it.
This is why companies increasingly choose the faster route even when the eventual headcount converges. They are not buying a cheaper team. They are buying the same team sooner.
Months from decision to a team at full velocity
The compression comes from running compliance, facilities and hiring in parallel against infrastructure that already exists, rather than sequentially from zero.
The measurement shift underneath
There is a third change that gets less attention but matters as much. What these centers are asked to prove has changed.
A center justified purely on cost savings is permanently vulnerable, because there is always a cheaper hour somewhere. That argument works once, at approval, and then works against the team every year afterwards.
Smaller, mandate-specific centers tend to be measured differently: on what they built, what IP they own, how much roadmap capacity they freed. That framing is more durable, and it also changes team composition, because outcomes require seniority in a way that throughput does not. See the Value Generation Framework for the specific measures.
| Dimension | Emerging model | Traditional model |
|---|---|---|
| Sized by | The mandate | A headcount target |
| Launch timeline | 3 to 4 months | 9 to 18 months |
| Fixed overhead carried by | Partner, amortised | Parent company |
| Measured on | Value created, IP owned | Cost per hour, throughput |
| Seniority profile | High, small team | Mixed, large team |
| Reversibility | High, low wind-down cost | Low, significant commitment |
| Who can realistically use it | Growth stage upward | Large enterprise |
Both models remain valid. The difference is which question each one answers well.
Is the traditional model obsolete?
No, and it is worth being precise about this rather than overclaiming.
If you are moving several broad functions simultaneously, expect to employ many hundreds of people, and can absorb a long build, a traditional captive center remains appropriate and well understood. At sufficient scale, carrying the entity yourself becomes economically rational rather than burdensome.
What has changed is that this is no longer the only shape available, and it is no longer the correct default. Choosing it because it is familiar, when the actual requirement is fifteen engineers owning one thing, costs a year and produces an overbuilt structure. That specific mistake is what the shift is correcting.
A useful test. If you can state the mandate in one sentence, the smaller model almost certainly fits. If stating the scope takes a paragraph and spans several functions, the traditional model may genuinely be the honest answer.
What this means if you are deciding now
Three practical implications follow from the shift, and all three change how the decision should be approached.
Scope the mandate before scoping the team
Team size should be an output of the mandate, not an input agreed in advance. Starting from a headcount number reliably produces either an overbuilt team or an underspecified one.
Treat the timeline as a variable you control
A year is no longer an unavoidable cost of entry. If a plan assumes one, that assumption should be examined rather than inherited from how this used to work.
Decide what you will measure before you build
Agreeing outcome measures at approval is far easier than retrofitting them onto a team already running, and it determines the seniority you should hire for.
Frequently asked questions
Why are Nano GCCs growing so quickly?
Because the fixed overhead that forced capability centers to be large is now carried by partners and amortised across many clients, while AI tooling simultaneously reduced the headcount a given mandate requires. Both changes point the same direction.
Does this mean traditional GCCs are failing?
No. Large captive centers continue to work well for broad, steady state functions at significant scale. What changed is that scale is no longer a precondition for having a center at all.
Is a Nano GCC just outsourcing with a new name?
No. Outsourcing hands work to a vendor team you neither control nor retain. A Nano GCC is your own dedicated team, embedded in your roadmap and retained long term, employed through a partner entity rather than your own.
What size company can use this model?
Growth stage and upward. The model exists precisely to serve companies that would benefit from a dedicated India team but could not previously absorb the fixed cost of establishing one.
How long does a modern center take to launch?
Three to four months to full operational velocity is typical when compliance, facilities and hiring run in parallel rather than sequentially.
Can a small center grow into a large one?
Yes, and this is the common path. Many companies start with one mandate, expand as it proves out, and convert to a captive structure once headcount justifies carrying the entity directly.
What is the main risk with the smaller model?
Underestimating compliance. A smaller team does not mean smaller statutory obligations, so the quality of the partner carrying that layer matters more, not less.
How should we decide between the two models?
Start from scope and timeline. One named capability needed this year points to the smaller model; several broad functions with a year of runway points to the traditional one.
Conclusion
The replacement of the traditional model is not a story about one approach beating another. It is a story about a barrier being removed, and about the range of companies that can now make this decision expanding considerably as a result.
For twenty years the question was effectively “are we large enough to justify a center in India”. For most companies evaluating it now, that question no longer applies, and the useful question has become “what capability do we need owned, and how quickly”.
That is a better question, and it produces better decisions. It is also why the shape of the answer has changed.
What the shift looks like in practice
Abstract arguments about fixed cost amortisation are easy to accept and hard to act on. It is more useful to look at what actually changes in the three situations where companies most often face this decision.
The capability you cannot hire for
A company needs four senior AI engineers and cannot fill the roles domestically inside the roadmap window. Under the old model, the India option required committing to a scale far beyond four people. Under the new one, four is a legitimate team.
The roadmap area that keeps slipping
An area gets deferred every planning cycle because the core team is fully allocated. A dedicated pod owning it removes the competition for attention, and it can exist within a quarter rather than a year.
The bet you want de-risked first
Rather than committing core team bandwidth to an unproven direction, a small time-boxed team validates it and returns a clear scale, hand off or stop decision. This was never economic at traditional scale.
The reversibility argument
One underrated consequence of the smaller model is how much cheaper it is to be wrong. Winding down a partner-operated team of fifteen is a contractual conversation. Winding down a captive entity of four hundred is a legal, financial and reputational project measured in quarters.
That asymmetry matters more than it appears, because it changes what you are able to attempt. When the downside of a failed initiative is bounded and modest, a company can justify trying things it would never approve if the commitment were irreversible. Lower exit cost quietly raises the number of good bets you can take.
- Fixed overhead is carried by the partner and amortised across their portfolio
- Team size follows the mandate rather than a headcount target set in advance
- Capability arrives in a quarter, which changes what is worth attempting
- Exit cost is low, so being wrong is survivable and therefore attemptable
- IP is assigned to your entity outright, exactly as in a captive structure
Evaluating a capability center this year?
Tell us the mandate you need owned. We will come back with a team shape, a realistic timeline and an all in cost model you can take to your board.