How to Set Up an ODC: The 90-Day Playbook From Role Map to Real Work

Nguyen Manh Thang Chief Executive Officer, AgileTech Vietnam

Published: August 21, 2026
Read time: 13 min

In short

Setting up an offshore development center takes roughly 90 days done properly: two weeks to define the roles, the standards and the pilot scope in writing; four to six weeks for the partner to hire against your role map with you inside the final interview; two weeks of onboarding onto your codebase, your tooling and your definition of done; and a four-week pilot on real but low-risk work before the team takes production scope. The steps that decide success are the unglamorous ones: a named lead on each side, a fixed daily overlap window, a written decision trail, and contract terms that settle code ownership, replacement of underperformers and exit before anyone writes a line of code.

Most offshore development center failures are setup failures that surface later. The team that goes quiet in month four was hired without an anchor in month one. The rewrite that eats quarter three was a pilot that never happened in quarter one. The ownership dispute at exit was a contract clause nobody read at signing. By the time the symptom appears, the cause is months old and expensive to reach.

This playbook runs the setup in the order that prevents those failures: a readiness test you run on yourself, the partner terms that actually matter, a role map and hiring loop that keep your bar in the room, onboarding as a system rather than a wiki link, a pilot that calibrates before production work arrives, and the operating rhythm that holds it all together after the novelty wears off.

It assumes you already know what an ODC is and have decided you want one. If you are still weighing the model itself, start with our offshore development center guide, which defines the model against its alternatives and prices it honestly. And if the location question is still open, the trade-offs are mapped in onshore, nearshore or offshore. This page begins where those end: you want a standing offshore team, and you want it set up so it still works in year two.

Key takeaways

An ODC setup is a 90-day project with your name on it, not a purchase. The partner hires, employs and houses the team; you define the roles, hold the interview bar, supply the pilot scope and run the operating rhythm. Teams that treat setup as delegated get the team the partner found easiest to staff.
Run the readiness test before the partner search: a roadmap longer than a year, a named lead with real hours to direct the team, and work that can be carved into an honest pilot. Missing any one of the three points you toward project outsourcing or a smaller engagement instead.
The contract earns its length in four clauses: who owns the code from the first commit, how underperformers are replaced and how fast, what the exit terms are including knowledge transfer, and what the partner may not do with your engineers between your sprints. Everything else is boilerplate.
Hire the anchor first: a senior engineer or team lead who will carry your standards into every later interview. A team hired around a strong anchor converges on your bar; a team hired flat converges on the partner average.
The pilot is a calibration exercise, not a trial by fire: four weeks of real but low-risk scope, with the same review standards production work will face. Its job is to surface the communication and quality gaps while they are cheap to fix.
What kills ODCs is drift, not distance: the overlap window erodes, decisions move into calls that nobody writes down, and by month six the team is executing a backlog nobody has re-prioritized. The weekly rhythm this playbook installs is the anti-drift machinery.

Step zero: the readiness test you run on yourself

The first qualification in an ODC setup is yours, not the partner's. The model is a standing team that you direct, which means it consumes something scarcer than budget: management attention, every week, indefinitely. Before any partner conversation, answer three questions in writing, because the honest answers route some readers away from this page entirely, and better now than at month six.

First: is the roadmap longer than a year? An ODC amortizes its setup cost, the hiring, the onboarding, the accumulated domain knowledge, across time. A six-month project does not repay that investment; it wants project outsourcing, where the vendor owns the how and you accept a deliverable. Signing a standing team for bounded work is renting a house for a weekend.

Second: who directs the team, by name, with hours? Not a committee, not "the CTO when free". An ODC without a named counterpart on your side, someone who owns the backlog, answers questions inside a day and holds the quality bar, decays into a body shop within a quarter. If no such person exists with genuine capacity, fix that first or choose a model that includes direction, because this one does not.

Third: can the work be carved into a pilot? A four-week slice that is real enough to exercise your review standards but low-risk enough that a rough first month costs learning rather than customers. Codebases where everything touches everything, or roadmaps that are one indivisible bet, make calibration impossible and turn month one into the trial by fire the pilot exists to prevent. If all three answers hold, proceed; the rest of this playbook assumes they do.

The readiness checklist, in writing before the partner search

A roadmap longer than a yearThe setup cost only repays across time. Bounded work wants project outsourcing, not a standing team.
A named lead with weekly hoursSomeone on your side who owns the backlog, answers within a day and holds the bar. A role, not a rotation.
A pilot-sized slice of real workFour weeks, real code, low blast radius. If no such slice exists, create one before hiring anyone.
Standards you can hand overA definition of done, review expectations and coding conventions that exist in writing, not in one engineer's head.
A budget that includes your timeThe invoice is the visible cost. The direction hours are the real one, and they do not scale down.

The setup as a swimlane plan: your work, the partner's work, and the joint work, phase by phase. The plan fails wherever a lane expects the other side to fill its cell.

Choosing the partner and signing the terms that matter

Partner selection for an ODC is a different exercise from selecting a project vendor, because you are not buying a deliverable, you are choosing who employs your future team. The evaluation weight shifts accordingly: portfolio case studies matter less, and the partner's engineering bench, retention record, hiring pipeline in your stack, and security posture matter more. The full evaluation method is its own article, how to evaluate a software partner; what follows is the ODC-specific layer on top of it.

Ask three questions whose answers must all point at the same place. Who employs the engineers? Who owns the code from the first commit? Who holds the security certifications the contract will lean on? Some markets are full of brokers who resell other companies' engineers; every layer between you and the employer adds a party who can fail, and none of them adds value. A partner who employs directly, assigns ownership to you contractually, and holds its own ISO 27001 or equivalent removes three risks in one answer.

The contract earns its page count in four clauses, and boilerplate handles the rest. Intellectual property: everything the team produces is yours from the moment it exists, including the pilot, with no license-back and no carve-outs for "tools and frameworks" broad enough to swallow your product. Replacement: a named process and a time bound for swapping an underperforming engineer, because the polite fiction that it never happens is how a weak hire stays for a year. Exclusivity: your engineers are not shared across other clients between your sprints. Exit: notice period, knowledge-transfer obligations, and what happens to in-flight work, negotiated now, while you have leverage, not at departure, when you have none.

Price the engagement honestly while you are here. The monthly rate card is the visible line; the real first-year cost adds your recruitment involvement, the onboarding weeks where the team learns rather than ships, equipment or license costs the contract assigns to you, and the management hours from the readiness test. A partner whose quote is dramatically below market is answering a different question than the one you asked, usually by planning to staff juniors against a senior role map, which is exactly what the hiring loop in step three exists to catch.

The four contract clauses that decide the engagement

Clause	What it must say	The failure it prevents
Intellectual property	All work product is yours from creation, pilot included, no license-back	An ownership dispute at exit, when leverage is gone
Replacement	Named process and time bound for swapping an engineer who is not working out	A weak hire staying a year because raising it feels rude
Exclusivity	Your team works on your product only, not shared between your sprints	Velocity that mysteriously halves when the partner lands a new client
Exit and transfer	Notice period, documented knowledge transfer, disposition of in-flight work	A departure that takes the domain knowledge with it

Everything else in the contract is boilerplate. These four are worth legal review line by line.

The readiness test as a router. Two of the four paths lead away from the model, which is the honest shape of the decision.

The role map: designing the team before hiring it

A role map is one page per role: the responsibilities, the seniority, the specific skills that are load-bearing versus trainable, and the first three months of work the person will actually do. Writing it forces the decision most buyers skip: what shape of team do you need, rather than how many engineers. A partner handed a headcount will staff a headcount; a partner handed a role map can be held to it.

The anchor role comes first, and it is the highest-leverage decision in the entire setup. The anchor is a senior engineer or team lead, hired before everyone else, who will sit in every subsequent interview and carry your standards into the team as it forms. A strong anchor turns the partner's pipeline into your team; a missing anchor means the team converges on whatever the partner's average happens to be. Pay the senior rate without flinching, and involve your best engineer in this hire even if they sit out all the others.

Size the first team small and slightly senior. Three to five engineers around the anchor is enough to prove the model and small enough to onboard properly; a ten-person day-one team multiplies every setup mistake by ten. Weight the mix toward mid and senior levels at the start, because early ODC work is full of ambiguity, undocumented context, unfamiliar conventions, questions with no local answer, and ambiguity is exactly what junior engineers are worst positioned to absorb. Juniors join well at month six, into a team that can mentor them.

Decide the interface roles deliberately. Does the ODC get its own QA, or does it share yours? Its own DevOps capability, or access to your platform team? A designer, or finished designs? Each shared function is a dependency crossing time zones, and each dedicated one is headcount. The honest default for a first team: dedicated QA from day one, because quality feedback loops suffer most across the time gap, and shared everything else until the pilot shows where the seams actually are.

Team design: what works in the first quarter

Do this

Hire the anchor first, aloneOne senior hire who then interviews everyone else. Your standards enter the team through this person or not at all.
Start at three to five, slightly seniorSmall enough to onboard well, senior enough to absorb ambiguity. Scale after the pilot proves the model.
Write the first ninety days into each roleA role map with real work attached staffs honestly. A title list staffs whoever is on the bench.
Give the team dedicated QA earlyQuality feedback loops suffer most across time zones. A tester inside the overlap window shortens them structurally.

Not this

Ordering a headcount"Six engineers" is a quantity, not a team. The partner will fill it with whoever is available, and the gaps surface as missed sprints.
Staffing juniors into ambiguityEarly ODC work is undocumented context and unanswerable questions. Juniors thrive at month six, not day one.
Splitting one team across two clientsIf the contract allows shared engineers, velocity becomes a function of the partner's other deals. Exclusivity is the point of the model.
Skipping the lead because you have one at homeA remote team with no local lead routes every decision through the time gap. The overlap window becomes a bottleneck by week three.

The hiring loop: staying inside your own bar

The partner runs the pipeline; you own the bar. That division holds only if you stay inside the loop at the point where it matters: the final technical interview. Partners screen for availability and general competence, both real filters, but neither one is your bar, and the difference between "competent" and "right for this codebase" is precisely the judgment you cannot delegate. Every engineer who joins the team should have passed an interview that your anchor, or your own senior engineer, conducted.

Keep the loop short and honest. Two stages beyond the partner's screen is enough: a technical interview against the actual work, using a problem from your real domain rather than a puzzle, and a conversation with the lead they will report to. Long loops lose good candidates in competitive markets, and they signal indecision to the partner, who will quietly start routing stronger candidates to clients who move. Agree turnaround times in advance: partner presents, you respond within three business days, offer within a week of the final interview.

Interview for the failure mode of the model, not just the craft. Distributed teams fail on communication, so test it: have the candidate explain a past technical decision and its trade-offs, in the language the team will work in, and watch for the difference between someone who describes and someone who justifies. Ask how they handled a disagreement with a specification. An engineer who asks clarifying questions in the interview will ask them on the job, and an engineer who codes confidently into ambiguity will do that on the job too, at production scale.

Expect the pipeline to take four to six weeks for the first team, and treat that as information rather than delay. A partner who presents five strong candidates in week one either has an exceptional bench or is showing you profiles that will be "suddenly unavailable" after signature, a bait-and-switch old enough to have a name. A partner who presents nobody for three weeks lacks the pipeline in your stack, and the time to learn that is before the contract locks you in. The hiring loop is your first real look at how the partner actually operates; grade it.

The hiring loop, stage by stage

Partner screenOngoing

The partner filters for availability, stack fit and baseline competence from its pipeline. You see profiles that pass, with honest notes.
Technical interview, your barWithin 3 days of presentation

Your anchor or senior engineer interviews against real domain problems. This is the stage that cannot be delegated.
Lead conversationSame week

The person they will report to tests communication, judgment and the shape of past disagreements. Craft was stage two; this is fit.
Offer and start dateWithin a week of final

The partner extends the offer and handles notice periods, which run long in many markets. Onboarding prep starts now, not on day one.

Illustrative timelines from signature to the team carrying production scope. Skipping steps looks faster on the calendar and costs the difference back with interest.

Onboarding as a system, not a wiki link

Onboarding is where setup investment compounds or evaporates. An engineer who spends week one blocked on repository access, guessing at conventions and afraid to ask, converts that experience into month-three behavior: quiet, cautious, dependent. The fix is to treat onboarding as a system you build once, before the first start date, and improve with each hire, because an ODC that works will onboard engineers for years.

The access layer comes first and is pure logistics: accounts, repositories, environments, licenses, VPN, and the security onboarding your compliance posture requires, all provisioned before day one. Assign it an owner and a checklist, because access friction is the most common and most preventable week-one failure, and it lands entirely on your side of the engagement. An engineer who commits code on day two believes this team ships; an engineer who waits four days for credentials learns the opposite lesson first.

The context layer is the actual work. A codebase walkthrough recorded once and reused. An architecture document that says why, not just what. Your definition of done, your review standards, your branching model, written down at last if they never were, which is a benefit of the ODC forcing function that your local team will quietly thank you for. And a starter task on day two: small, real, shippable inside a week, chosen so the first pull request exercises the whole loop from ticket to review to deploy while the stakes are near zero.

The relationship layer is the one skipped most. Introduce the ODC engineers to the humans behind the code, in a real call with faces, not a distribution list. Name their go-to person for questions and make asking explicitly welcome, because the default failure mode of a new remote engineer is silent stuckness, and it is cheaper to over-invite questions for a month than to excavate a wrong assumption from the codebase in quarter two. The anchor carries much of this layer, which is one more reason the anchor was hired first.

The pilot: four weeks of calibration on real work

The pilot is the most misunderstood step in the sequence, so state its purpose plainly: it is calibration, not audition. The hiring already happened; you are not deciding whether to keep the team, you are surfacing the gaps between how they work and how you work while the cost of a gap is a conversation rather than an incident. Teams that skip the pilot do not skip the calibration; they run it on production scope, in front of customers, at incident prices.

Choose the scope with three properties. Real: code that ships to the actual product, because sample projects calibrate nothing and everyone can smell them. Bounded: four weeks with a defined end state, so the pilot produces a verdict rather than trailing off. Low blast radius: a feature or internal surface where a rough edge costs polish time rather than customer trust. An internal tool rebuild, a well-contained feature behind a flag, a test coverage push on a critical module: all honest pilots. A payment flow is not.

Run it at full production standards, which is the entire point. Same review bar, same definition of done, same ticket hygiene, same deployment process. Softening standards for the pilot, out of politeness or pragmatism, calibrates the team against a bar that will move later, and the move will land as betrayal. The pilot should also exercise the operating rhythm from the next section, standup cadence, demo, decision log, so that month two continues a machine that is already running rather than starting one.

Close the pilot with a structured retrospective on both sides, and grade the engagement rather than the individuals. Where did work wait, and on whom? Which questions took longer than a day to answer, and why? Did review comments land as teaching or as gatekeeping? What did the partner see from their side that you missed? The output is a short list of process fixes, owned and dated, and the confidence, in both directions, to put production scope on the calendar. That confidence, earned on cheap work, is what the pilot was for.

Pilot vocabulary, defined by what each term commits you to

Calibration scope: Real, bounded, low-risk work used to align standards and rhythms. Ships to the product; a sample project is not one.
Full-bar rule: The pilot runs under production review standards. A softened bar calibrates the team to expectations that will move.
Blast radius: What a defect in the pilot scope can damage. Internal tools and flagged features keep it small; customer-facing money flows do not.
Two-way retrospective: A structured close where both sides grade the engagement, not the people. Produces owned, dated process fixes.
Production gate: The explicit decision, after the retrospective, that the team takes real roadmap scope. Making it explicit makes it honest.

The operating rhythm that survives month three

Everything before this section is setup; this section is the machine that runs afterward, and it is where ODCs actually live or die. The failure mode is never dramatic. It is drift: the overlap window erodes meeting by meeting, decisions migrate into calls nobody writes down, the backlog stops being re-prioritized, and by month six a competent team is efficiently building things nobody has recently confirmed anyone wants. The rhythm exists to make drift visible weekly instead of quarterly.

Fix the overlap window first and defend it like infrastructure. Two to three shared hours daily, at a time both sides can genuinely sustain, holding everything synchronous: standup, blockers, decisions that need a conversation, pairing. Outside the window, the engagement is written by default, and that is a feature. Asynchronous writing produces the decision trail that remote teams need and co-located teams never bother to create; a well-run ODC is often better documented than the home team within a year.

Install a decision log and make it the habit that outlives enthusiasm. One page, append-only: the decision, the options considered, who made it, when. Not for bureaucracy, but because the alternative is decisions living in call recordings and chat scrollback, where they are unfindable precisely when they matter, at handover, at incident, at "why is it built this way" in month nine. Pair it with a weekly demo of working software, which keeps progress honest, and a monthly working session between your lead and the partner's delivery manager on the health of the engagement itself: velocity trend, retention risk, upcoming hiring, the state of the machine.

Finally, measure the things that predict trouble rather than the things that are easy to count. Time-to-answer on questions crossing the time gap: when it stretches past a day, the team is about to start guessing. Review turnaround in both directions: when your side becomes the bottleneck, the ODC learns to batch work, and batching hides problems. Ratio of decisions in the log versus decisions you can remember making: when the gap grows, drift has started. None of these appear on an invoice, and all of them are cheaper to read weekly than to reconstruct at the post-mortem.

The rhythm, in three defended numbers

2 to 3 hours Daily overlap window, held synchronous Standup, blockers and decisions live here. Outside it, the engagement is written by default, which builds the decision trail.

Under 1 day Time-to-answer across the gap The predictive metric: when answers stretch past a day, the team starts guessing, and guesses ship. Illustrative threshold from delivery practice.

Weekly Working software demo cadence The honesty mechanism. A demo skipped twice is a status report; a status report is where drift hides.

Illustrative engagement health at month six, comparing a team running the operating rhythm against the same setup after drift. The metrics are the predictive ones, not the invoice.

Scaling the team, and the failure signals worth acting on

Scale after the machine works, and scale the way you started: role map, anchor-involved interviews, systematic onboarding, in cohorts of two or three rather than leaps. Each cohort should be absorbed, productive and rhythm-native before the next arrives, because onboarding load lands on the existing team, and a team that doubles overnight spends a quarter teaching instead of shipping. This is also where junior engineers finally enter well: into a stable team with slack to mentor, rather than into day-one ambiguity.

Growth changes the shape of the team before it changes the size of the invoice. Somewhere between eight and twelve engineers, the single anchor stops scaling and the team wants structure: a second lead, or a split into two squads with their own scope. Take the fork deliberately rather than letting it happen, because an unstructured twelve-person team defaults to routing everything through one exhausted anchor, and the anchor burning out is one of the more expensive single points of failure in the whole model.

Watch for the failure signals that setup quality predicts. Velocity that halves without explanation suggests your engineers are being shared, which is what the exclusivity clause was for. A partner who resists your presence in interviews as the team grows is drifting back toward staffing a headcount. Attrition above the local market norm is a partner-side management problem you are paying for. And the quiet team, no questions, no pushback, no surprises in the demo, is not a good sign but the worst one: healthy teams generate friction, and silence means the friction went somewhere you cannot see it.

Know the exits, because knowing them changes behavior on both sides. The good exit is graduation: some companies eventually convert a mature ODC into their own legal entity, hiring the team they already trust, and a confident partner will discuss that path at signing. The managed exit is the contract's transfer clause doing its job: notice, documentation, handover, on terms you set in month zero. The bad exit is the one negotiated during a dispute, which is precisely what the four contract clauses from step two exist to prevent. Set up well, most engagements never need any of the three, which is the quiet argument for doing the setup well.

Your next move, routed by where you are

Where does your ODC plan actually stand?

Roadmap under a year, or no named lead with real hours

Do not set up an ODC yet

The model consumes weekly direction and repays over years. Bounded work wants project outsourcing; a missing lead wants an org fix first.
Ready, but no partner chosen

Run the partner evaluation with the four ODC clauses on the table

Employment, ownership, replacement and exit terms are cheaper to negotiate before signature than after dependence.
Partner signed, team not yet hired

Write the role map and hire the anchor first

The anchor carries your bar into every later interview. Everything else in the setup compounds from this hire.
Team running but drifting

Reinstall the rhythm: overlap window, decision log, weekly demo

Drift is a process failure, not a people failure. The machinery in this playbook retrofits; start with the demo.

Four situations that settle what to do next in the setup sequence.

Who holds what in a healthy engagement: direction on your side, employment on the partner's, and a joint interface where the daily work actually happens.

Frequently asked questions

How long does it take to set up an offshore development center?

Roughly 90 days from contract to a team carrying production work, done properly: about two weeks to write the role map, standards and pilot scope; four to six weeks of hiring with your bar in the final interview; two weeks of systematic onboarding; and a four-week pilot at full production standards before the production gate. Faster is possible by skipping steps, and each skipped step converts setup weeks into rework months.

What should an ODC contract include?

Four clauses do most of the work: intellectual property assigning everything to you from the first commit with no license-back; a named replacement process and time bound for underperforming engineers; exclusivity, so your team is not shared across the partner's other clients; and exit terms covering notice, knowledge transfer and in-flight work. Also verify that the partner directly employs the engineers and holds its own security certification, so the entity you contract with is the entity carrying the obligations.

How many engineers should an ODC start with?

Three to five, built around a senior anchor hired first. That is large enough to prove the model and small enough to onboard well. Weight the initial mix toward mid and senior levels, because early ODC work is full of ambiguity that junior engineers are poorly positioned to absorb; juniors join well from around month six, into a stable team with capacity to mentor. Scale afterward in cohorts of two or three, absorbed fully before the next arrives.

Should I interview ODC engineers myself?

Yes, at the stage that matters: the final technical interview, conducted by your anchor or your own senior engineer against real problems from your domain. The partner's screen filters for availability and general competence, which is useful but is not your bar. Teams whose engineers all passed a client-side interview converge on the client's standards; teams hired entirely by the partner converge on the partner's average. Keep the loop short, two stages beyond the screen, with agreed turnaround times.

What is the purpose of an ODC pilot project?

Calibration, not audition. The pilot is four weeks of real but low-blast-radius work, run at full production standards, whose job is to surface the gaps between how the team works and how you work while a gap costs a conversation instead of an incident. It should exercise the whole loop, ticket to review to deploy, and close with a two-way retrospective producing owned, dated process fixes and an explicit production gate decision.

Why do offshore development centers fail?

Mostly drift, not distance or skill. The overlap window erodes, decisions migrate into calls nobody writes down, the backlog goes stale, and a competent team ends up efficiently building unconfirmed priorities. The prevention is machinery, installed at setup: a defended two-to-three-hour daily overlap window, an append-only decision log, a weekly demo of working software, and a monthly engagement-health session. The predictive warning signs are time-to-answer stretching past a day and a team that has gone quiet.

A standing offshore team is a 90-day setup project: role map, anchor hire, systematic onboarding, a calibration pilot and the weekly rhythm that prevents drift. When you want that machinery run by people who have built it before, set up your ODC with AgileTech in Hanoi, where the interview bar stays yours and the pilot runs at full production standards.