Offshore Development Centre in India: A Practical Setup Guide

An ODC is not a cheaper contractor. It is a second office that happens to be somewhere else.

Companies that get value from an offshore development centre treat it that way from week one. Companies that run it as a ticket queue usually get exactly that: a ticket queue.

We have run this model from Pune since 2018, across 730+ projects, 500+ clients and 25+ verticals.

What an Offshore Development Centre in India Actually Is

Three engagement models are often described using similar language, but they operate very differently.

Offshore Development Centre (ODC): You set priorities weekly, while the delivery partner manages the people according to your standards. The contract is generally structured around rolling monthly dedicated seats. The provider handles attrition and team continuity.

A practical ODC usually starts with four to six people. At the end, you retain the code, documentation, tests and potentially a transfer option.

It works best when you have a continuous roadmap without a defined end date.

Staff Augmentation: You set priorities and directly manage individual developers. It works well when you need one or two specific skills for a limited period.

You receive the code, but your organisation carries much more of the management burden.

Project Outsourcing: The scope and milestones are agreed at the beginning, and the vendor manages delivery. It works best when the project has a clearly defined finish line.

If your work has an end date, buy a project. If you need two React developers for four months, staff augmentation may be enough.

An ODC earns its keep when the work is continuous, domain knowledge compounds over time, and you want the same engineers working with you eighteen months later.

Team Composition That Works

Start with a working tech lead who writes and reviews code, not simply a project manager.

On a six-person pod, our default structure is:

1 Senior Engineer → 3 Mid-Level Engineers → 1 Junior Engineer → 1 QA Engineer

Not one senior engineer supported by five juniors.

Senior engineers prevent multiple developers from spending weeks building around the wrong technical assumption.

QA should also be involved from week one.

Building your regression suite while the codebase is small is considerably easier than introducing QA after hundreds of files and multiple releases already exist.

The First 12 Weeks

Ramp-up is where many ODC relationships are quietly decided. The client’s involvement during this period matters as much as the engineering team's work.

Week 1 — Setup
We confirm contracts, accounts and roles. You provide a named internal owner, repository access and tool access. By the end of the week, the team and accounts should be ready.

Week 2 — Environment
The team builds its development environment and starts understanding the codebase. You provide an architecture walkthrough. Everyone should be able to run the system locally.

Week 3 — Shadowing
The ODC shadows your sprint without committing directly to main. The goal is to produce and review a system map.

Week 4 — First Code
The team takes small, low-risk tickets. Your team provides code-review support. The first pull request should be merged.

Week 5 — Definition of Done
A written definition of done is created and agreed upon.

Week 6 — QA Ownership
QA begins taking responsibility for regression testing, with the suite running against pull requests.

Week 7 — First Full Sprint
The pod owns its first complete sprint from start to finish.

Week 8 — Reporting
The first structured weekly report is introduced.

Week 9 — Escalation
The on-call and escalation process goes live and is tested.

Week 10 — Baseline
Velocity is measured across comparable sprints.

Week 11 — Documentation
Documentation debt is addressed and the runbook is tested to determine whether a new team member could follow it.

Week 12 — Ramp Review
The team structure and performance are reviewed, followed by a written 90-day plan.

Weeks one to four may produce relatively little visible output. That is not necessarily a problem.

An ODC shipping major features in week two may have skipped the system-mapping and discovery work that becomes important later. Pasted text

Governance That Prevents the Classic Failure

A common failure is having a team that looks busy while the client cannot determine whether that activity is producing useful outcomes.

Four practices help prevent this.

One named counterpart on each side. Both should be able to answer questions quickly and make scope decisions.

A written weekly report. Record what shipped, what slipped, what is blocked and who owns the next action.

A written definition of done. This should cover code review, test coverage for new code, documentation and deployment to staging.

A real escalation path. Define response windows and name the person responsible. “Email us” is not an escalation process.

IP, Code and Data

The repository should sit inside your organisation from day one, whether you use GitHub, GitLab or Azure DevOps. The offshore team participates as contributors whose access can be revoked.

IP assignment also needs careful contractual treatment in India.

Under Section 19 of the Copyright Act 1957, copyright assignment must be written and signed. If the assignment does not specify a period, the statutory default is five years. If territory is not specified, the default extends only to India.

The agreement should therefore clearly identify the work and state the agreed term and territory.

Production-data location should also be defined in the agreement.

Deployment can be made to AWS, Azure or Google Cloud Platform in the required region, or to the client's own on-premise infrastructure.

Accucia is currently implementing an ISO 27001 information security management system. An auditor has been appointed, with certification targeted for Q1 2027.

Accucia is not ISO 27001 certified today. ISO 9001 is also in progress, and Accucia does not hold CERT-In empanelment. Pasted text

Build Operate Transfer, Explained Honestly

In a Build Operate Transfer model, the provider recruits and operates the team for an agreed period before transferring the entity, employees or both to the client.

That option should be written into the contract from day one.

A realistic transfer can take 24 to 36 months because you are transferring a functioning team, not simply a list of developers.

Code, documentation, tests, infrastructure and employment contracts can transfer.

What is harder to transfer is informal system knowledge.

That knowledge lives with the engineers who have worked through technical decisions over several years, which makes retention planning important.

Local management also remains a genuine responsibility. Payroll, office operations, statutory compliance and recruitment do not disappear simply because ownership changes.

Timezone Overlap: The Actual Hours

Accucia's standard India working day is 09:30 to 18:30 IST.

The practical overlap differs considerably by market.

UK: Approximately 4 hours during standard time and 5 hours during summer time. A shifted 11:00–20:00 IST roster can provide roughly 5.5–6.5 hours.

Western and Central Europe: Approximately 5 hours normally and 6 hours during summer time. A shifted roster can increase this to around 6.5–7.5 hours.

UAE: Approximately 8 hours of overlap. A shifted roster is generally unnecessary.

Saudi Arabia and Bahrain: Approximately 7 hours of overlap.

US Eastern: A normal Indian workday provides effectively no standard overlap. A 14:00–23:00 IST roster can provide approximately 3.5–4.5 hours.

US Pacific: A standard Indian workday provides no useful overlap. A dedicated 18:00–03:00 IST roster can provide approximately 4.5–5.5 hours.

Australia Eastern: Approximately 2–3 hours on a normal India schedule, depending on daylight saving. A 07:00–16:00 IST roster can increase this to approximately 4.5–5.5 hours.

The US Pacific example is especially important.

There is no realistic way to create useful Pacific-time overlap using a standard Indian workday. The practical solution is a separately staffed evening roster rather than expecting a normal day team to continuously work late. Pasted text

What Goes Wrong

Most ODC failures are surprisingly predictable.

No internal owner. The offshore team asks a question, waits several days, makes an assumption and builds the wrong thing.

Requirements arrive as meeting notes. A transcript is not a specification. Acceptance criteria should exist in the ticket before development begins.

The ODC becomes a ticket queue. Engineers who never see customer context or understand what happened after a release can only deliver literal compliance.

One capable person on the client side spending even half a day each week making decisions can prevent many of these problems.

What an ODC Costs

A single offshore development rate rarely tells you much without knowing the structure of the team.

Seniority mix is usually the biggest driver. A senior-heavy pod can cost close to twice as much as a junior-heavy pod with the same number of people, while potentially delivering better economics per unit of working software.

Scarce skills also increase cost. Platform engineers, data engineers and developers with genuine production experience in large language model systems typically command different rates from general application developers.

Compliance requirements can add engineering work through on-premise deployments, restricted devices and external audits.

Contract length also matters because longer commitments make forward hiring and team planning easier.

Infrastructure is billed separately at cost. Pasted text

When an ODC Makes Sense

An ODC is a management commitment before it is a procurement decision.

If you cannot identify the person inside your organisation who will spend approximately half a day each week owning the relationship, the model becomes much harder to operate successfully.

There are also situations where another engagement model makes more sense.

If your roadmap has a clear finish line, consider a fixed-scope project.

If you primarily operate on US Pacific time and cannot fund a dedicated evening roster in India, nearshore development may offer more convenient working-hour overlap.

If your total requirement is fewer than four people, you may effectively be buying staff augmentation regardless of what the engagement is called.

An offshore development centre works best when the roadmap is continuous, domain knowledge becomes more valuable over time, and the organisation wants a stable engineering team rather than temporary development capacity. Pasted text

Frequently Asked Questions

What is an Offshore Development Centre?

An ODC is a dedicated engineering team located in another country that works for one client using that client's tools, backlog and standards. The provider employs and manages the team, while the client determines priorities and owns the code.

How is an ODC different from staff augmentation?

With staff augmentation, the client directly manages individual developers and absorbs more of the impact of absences, resignations and skill gaps.

With an ODC, the provider manages the pod, maintains team continuity and takes responsibility for delivery against agreed standards.

Is an ODC the same as a GCC?

No.

A Global Capability Centre is typically a legal entity owned by the company, with its own payroll, office and compliance obligations in India.

An ODC is a service purchased from a provider. Build Operate Transfer can provide a path between the two models.

How long before an ODC becomes productive?

Expect limited output during the first four weeks.

The first merged code may arrive around week four, the team can own a complete sprint around week seven, and a stable velocity baseline can emerge around week ten.

Who owns the code?

The client owns the code, and the repository should sit inside the client's organisation from day one.

IP assignment should also be explicitly documented in the contract.

Where does production data sit?

Wherever the client requires.

Deployment can use AWS, Azure or Google Cloud Platform in the required region, or the client's own on-premise servers.

What is the smallest practical ODC?

A practical starting point is generally four to six people, including a working tech lead and QA capability.

Below four people, staff augmentation may provide a simpler model.

What drives ODC cost in India?

The major variables are seniority mix, skill scarcity, compliance requirements and contract duration.

The structure of the team matters more than a headline hourly or monthly rate.