The Offshore Development Center Setup Process: What Happens in the First 90 Days

Setting up an offshore development center takes 6–8 weeks from signed agreement to first sprint. The first 90 days determine whether the ODC operates as an embedded engineering team or becomes another vendor management problem.

Most ODC failures happen in these first 90 days — not because the engineers are bad, but because the setup skips critical steps. The team starts coding before communication norms are established. The client assigns work without understanding the team’s ramp curve. Expectations misalign in week three and nobody addresses it until week twelve. This guide covers what should happen, week by week.

What happens in weeks 1–2: agreement and team design?

Weeks 1–2 are about structure, not code. The most important decisions happen before a single engineer is assigned.

Define the team composition precisely. Not "we need 4 developers" but "we need 2 senior backend engineers with Python and PostgreSQL experience, 1 senior frontend engineer with React and TypeScript, and 1 QA engineer with API testing experience." Vague requirements produce vague teams.

Agree on overlap hours. For US clients working with an India-based ODC, the standard overlap is 4–5 hours. Typically 7:00–11:00 AM IST (which is 6:30–10:30 PM EST or 3:30–7:30 PM PST). The overlap window is when synchronous communication happens — standups, pair programming, architecture discussions. Outside that window, work continues asynchronously.

Establish the communication stack. Slack for daily communication, Zoom or Google Meet for standups and reviews, Jira or Linear for task management, GitHub or GitLab for code. Decide now, not in week four when half the team is on Slack and the other half is using email.

Set the billing and reporting structure. Monthly retainer with time tracking. Weekly reports showing hours per engineer, tasks completed, and blockers. This transparency prevents the "I don’t know what they’re working on" problem that kills ODC relationships.

What happens in weeks 3–4: hiring and infrastructure?

The ODC partner recruits and screens candidates against the specifications from weeks 1–2. At a firm like Madgeek, the engineers are already on staff — no recruitment delay, just matching existing team members to the engagement. At larger firms that hire per-project, this step takes 3–6 weeks.

The client should interview the proposed engineers. Not a rubber stamp — a real technical interview. Ask the engineers to walk through a recent project. Ask them to explain a technical decision they disagreed with and how they handled it. This is the last checkpoint before committing to specific people for the next 6–12 months.

Infrastructure setup runs in parallel. Development environments, VPN access if required, source control permissions, CI/CD pipeline access, staging environments, and monitoring access. Every day of delay here is a day the team can’t start productive work.

Security compliance gets addressed now — not later. NDAs signed. IP assignment executed. Data handling agreements in place. If the client has SOC 2 or HIPAA requirements, the controls are validated before any code or data is accessed. Retrofitting compliance after three months of development is expensive and disruptive.

What happens in weeks 5–6: onboarding and first sprint?

Onboarding is the most underinvested phase. Companies spend weeks negotiating contracts and hours on onboarding. That ratio should be reversed.

Effective onboarding covers three layers. First, the product: what does the system do, who uses it, and what are the business rules that drive behaviour? The ODC team needs to understand the domain, not just the codebase. Second, the codebase: architecture overview, module responsibilities, deployment process, and the parts of the code that are fragile or poorly documented. Third, the team norms: how does the client team communicate, how are code reviews done, what’s the PR review turnaround expectation, and how are disagreements handled?

The first sprint should be deliberately scoped small. Two or three well-defined tasks that let the team deliver something real within two weeks. Not the most complex ticket in the backlog — something achievable that builds confidence on both sides. A successful first sprint sets the tone for the next twelve months.

Daily standups start from day one of the sprint. Keep them to 15 minutes. The format: what I did, what I’m doing, what’s blocking me. The real purpose of the standup isn’t status updates — it’s catching miscommunication early, before a misunderstood requirement becomes three days of wasted work.

What happens in weeks 7–8: finding the working rhythm?

By week seven, the honeymoon phase is over. The initial politeness gives way to real working dynamics, and this is when most problems surface.

Velocity is still ramping. A new ODC team typically reaches 50–60% of steady-state velocity by week 8 and 80–90% by week 12. If the client expects full velocity from sprint one, frustration builds fast. Set this expectation explicitly during onboarding: the ramp curve is 8–12 weeks, and it’s an investment that pays back for years.

Sprint retrospectives become critical now. What worked, what didn’t, what do we change. The retrospective is where communication misalignments get surfaced and fixed. If the team skips retros to "move faster," small problems compound into large ones.

Code review feedback establishes quality expectations. The first month of code reviews should be thorough and explicit. "This pattern isn’t how we do it" is fine as long as the preferred pattern is documented. By month three, the ODC team should be writing code that matches the client’s standards without being told.

What happens in weeks 9–12: proving the model?

By week nine, you should see three things that signal the ODC is working.

First, velocity is predictable. Sprint commitments are being met at 70–80%+ consistency. The team isn’t overcommitting or sandbagging — they’ve learned the codebase and their estimates reflect reality.

Second, communication is proactive. The team isn’t waiting for the standup to raise blockers. They’re Slacking when something is unclear, proposing alternatives when a requirement doesn’t make technical sense, and pushing back when timelines are unrealistic. This is the opposite of the stereotypical offshore team that says "yes" to everything. It’s what you want.

Third, the client team trusts the ODC team with real decisions. Not just executing tickets — contributing to architecture discussions, suggesting refactors, identifying technical debt. When the client’s CTO starts asking the ODC team lead for their opinion on a design decision, the relationship has crossed from "vendor" to "team."

If these three signals aren’t present by week 12, something structural needs to change. Usually it’s one of: the wrong people on the team (fix by swapping one or two engineers), unclear product ownership on the client side (fix by assigning a dedicated product contact), or insufficient overlap time (fix by adding one more hour of synchronous overlap).

What are the most common ODC setup mistakes?

Starting with code before establishing communication norms. The team writes code for two weeks based on ticket descriptions that were ambiguous. The code review reveals the interpretation was wrong. Two weeks wasted. Establishing how requirements are communicated and clarified prevents this.

Treating the ODC as a separate entity instead of an extension of the team. The most successful ODC relationships look like one team across two timezones, not a client team and a vendor team. This means shared channels, shared standups, shared retrospectives. If the ODC team has their own separate communication channel that the client doesn’t see, information silos form immediately.

Scaling too fast. Starting with 6 engineers when you should start with 3. The first three months are about building the working relationship and understanding the codebase. Adding engineers before that foundation exists means more people being unproductive for longer. Start small, prove the model works, then scale.

No dedicated client-side counterpart. The ODC team needs one person on the client side who owns the relationship — someone who answers questions, reviews work, and makes product decisions. When that role is shared across three people or doesn’t exist at all, the ODC team can’t get answers, velocity drops, and both sides get frustrated.

How Madgeek runs ODC partnerships

We’ve operated as an embedded engineering partner since 2017. Our ODC model is designed for one outcome: the client forgets the team is in a different timezone.

Every engineer on our ODC teams is a full-time Madgeek employee — no freelancers, no bench rotation, no surprises. The engineers who start your project stay on it. Our attrition rate is low because we pay above market, work on interesting projects, and don’t burn people out.

Our founder is directly involved in every ODC setup. Not as a formality — as the person who validates team composition, reviews the onboarding plan, and monitors the first three sprints. By the time the relationship is running smoothly, he steps back to architecture reviews and escalation support.

The typical engagement starts at $10,000–$15,000/month for a 3-person team and scales from there. Our longest ODC partnership has been running for multiple years. That’s the point — the first 90 days are an investment in a relationship that compounds. If you’re considering hiring offshore developers from India, the setup process described here is exactly how we start.