One model, five very different problems
The Nano GCC structure is consistent. What changes by industry is which systems are under-owned, what the controls have to look like, and what the team must be able to decide without asking.
Every version starts from the same constraint
A capability you need permanently, that you cannot hire for locally in a timeframe that keeps the plan alive.
The industries below look different and arrive at the same place. In each one there is a set of systems that will exist for years, that accumulate context nobody has written down, and that are under-owned because the senior hiring required to own them has stalled.
The Nano GCC answer is structurally identical in all five: a small senior team inside your own Indian entity, owning named systems end to end with the authority to decide, operational in three to four months. What differs is which systems, what the control environment has to look like, and where the decision boundary sits.
Where the model adapts
Each page covers the systems that go under-owned in that sector, the structure that fits, and the questions clients actually ask.
SaaS & Technology
Product surfaces you will still be improving in five years, where the roadmap is constrained by senior hiring rather than by budget or direction.
Healthcare & Health Tech
Capacity that cannot come at the cost of the control environment, where every third party is a permanent entry in a risk assessment.
FinTech & Financial Services
Ledger, payments and risk systems where continuity of the people operating them is itself a control.
Retail & E-Commerce
Catalogue, pricing and fulfilment systems that only get attention in the narrow window between recovery and change freeze.
Hospitality & Travel
Booking and distribution platforms that never close, staffed for a single time zone with a rota covering the rest.
Applied AI across all five
Model backed capability in every sector, where evaluation design and production operation matter more than model selection.
The same structure, tuned differently
These are the variables that actually change between industries. Everything else about the model is constant.
| Industry | What is under-owned | What drives the structure | Typical size |
|---|---|---|---|
| SaaS & Technology | Core product surfaces and platform | Senior hiring has stalled against a validated roadmap | 10 to 40 |
| Healthcare & Health Tech | Clinical data, interoperability, compliance engineering | Access control and avoiding a third party processor | 8 to 25 |
| FinTech & Financial Services | Ledger, reconciliation, payment rails, reporting | Continuity of operators as a control, audit posture | 10 to 30 |
| Retail & E-Commerce | Catalogue, pricing, checkout, fulfilment | The annual freeze cycle leaves no improvement capacity | 10 to 30 |
| Hospitality & Travel | Distribution, inventory, booking, pricing | Systems that never close, staffed for one time zone | 10 to 25 |
Size ranges are typical starting points rather than rules. The right number follows from how many systems the team is expected to own, not from a headcount target.
The parts that do not change
Whatever the sector, these are the design decisions that determine whether a capability centre works.
Ownership of something named
The team owns specific systems end to end, including the right to decide how they change. Capacity contributed to somebody else s system accumulates nothing.
Seniority weighted for judgement
A small team has no ambient context to absorb, so judgement has to be present in the headcount. This makes cost per head worse and cost per outcome better.
Your entity, your employees
The engineers work for you. IP chain is short, context stays, and no third party sits in the middle of your data flows or your vendor register.
A transfer with a date on it
A named system changes hands on a named day with the approval gate removed. Without that date, a ramp extends indefinitely by default.
The same path in every sector
Entity, compliance and the search
Company formation, payroll and statutory setup run in parallel with the senior pod lead search. Nothing is sequenced that can be parallelised.
Senior core in place
Pod lead first, then senior engineers and the decision maker. The lead interviews every later hire.
First productive output
Environments, access and domain context complete. Readiness is what gets measured until this point.
Ownership transfers
A named system transfers on a named date, with the onshore approval gate removed rather than relabelled.
The area widens
Adjacent systems follow as capability accumulates and escalation falls.
How to tell whether this fits your situation
Four questions settle it faster than any comparison of models. All four are about your situation rather than about us.
Will these systems exist in five years?
If yes, the team working on them should be permanent. If no, a vendor or contractor arrangement is almost certainly the better answer and we will say so.
Has senior hiring actually stalled?
Roles open for more than two quarters indicate an access problem rather than a cost problem, and that changes which structure makes sense.
Can you give the team something real to own?
A named system with the decisions attached. If the honest answer is that everything needs onshore approval, the model will not work regardless of who you hire.
Is there a sponsor who will protect it?
Capability centres are cut in the first difficult quarter when nobody senior owns them. This matters more than any other factor in whether one survives to become useful.
When we say no. If the underlying problem is prioritisation, unclear product direction or a delivery process that is not working, an offshore team will scale that problem rather than solve it. We would rather establish that in a first conversation than eighteen months in.
Nano GCC against the alternatives
The options differ far more on ownership, context and IP than on rate, and those differences compound over the life of a system.
| Dimension | Nano GCC | Staffing / contractors | Outsourced development |
|---|---|---|---|
| Who employs the engineers | Your Indian entity | A staffing firm | A vendor |
| IP position | Yours, short chain | Contract dependent | Vendor may retain background IP |
| Context accumulation | High and permanent | Resets on rotation | Stays with the vendor |
| Decision authority | Local, by design | Escalates by default | Contractual scope only |
| Time to first output | 3 to 4 months | 2 to 6 weeks | 2 to 6 weeks |
| Suits work lasting | Indefinitely | Under 12 months | Bounded programmes |
| Cost over 3 years | Lowest | Moderate | Highest with margin |
| What you have at the end | A team and owned systems | Nothing | Code without the reasoning |
Contractors and vendors are genuinely right for bounded work with a real end date. The comparison changes entirely once the work is permanent.
The decision is not really about cost. It is about whether you need the capability to still be there, and still be improving, in three years.
Frequently asked questions
What if our industry is not listed?
The five pages cover the sectors we work in most, and the model is not industry specific. The questions that determine fit are the same everywhere: are the systems permanent, is senior hiring the constraint, and can the team be given something real to own.
How is a Nano GCC different from an offshore development centre?
Size, seniority and ownership. A Nano GCC is deliberately small and senior heavy, and it owns named systems including the decisions about them. An offshore development centre is usually larger, more junior and scoped to execute work specified elsewhere.
What is the minimum viable size?
Eight to twelve people for a team that owns a system end to end. Below that, an employer of record arrangement usually makes more sense until the scope grows enough to justify an entity.
How quickly can we start?
Three to four months from decision to first productive output in every sector. Entity formation, compliance, infrastructure and hiring run in parallel, which is what removes most of the traditional timeline.
Do you handle the entity, payroll and compliance?
Yes. Entity setup, statutory compliance, payroll, benefits and the annual filing cycle are handled under one roof. That is the difference between a capability centre and a set of vendor relationships you coordinate yourself.
Who owns the IP?
You do. The engineers are employees of your Indian entity, their contracts assign work product to that entity, and an intercompany agreement assigns it onward to the parent. Short chain, no third party with divergent interests.
What if we are not sure the model fits?
Then the readiness assessment is the cheaper first step. It is designed to produce an honest answer including a negative one, because a capability centre built for the wrong problem is expensive in a way that takes two years to become visible.
Can you build more than one team?
Yes, and the second is substantially cheaper than the first because most of the fixed cost base is incurred once. That optionality is worth pricing into the first decision and is routinely left out of business cases.
Related reading
Start with the systems, not the headcount
Tell us which systems are under-owned and why hiring for them has stalled. We will come back with a team shape, a seniority mix, a fully loaded cost model and a realistic date.