Build-Operate-Transfer (BOT) is the hybrid model that promises the best of two worlds. A vendor stands up an offshore team for you, operates it for 2–3 years, then transfers the team to your ownership as a captive operation. Lower upfront capex than building a captive yourself; eventual ownership unlike pure outsourcing.
It's a clever middle ground when the structural assumption holds — that you genuinely want to own a captive team eventually. When that assumption doesn't hold, BOT is just expensive outsourcing with a takeover clause attached. A Virtual Delivery Center sits in a different part of the decision space, and the choice between them turns on a single question: does ownership of the team produce strategic value, or just inherited capex?
What BOT actually involves
The BOT lifecycle has three phases:
- Build (months 0–6). The vendor recruits, hires, trains, and tools up a team in their location. Customer pays a per-engineer markup over hosted-cost. Customer has visibility but doesn't own the team.
- Operate (months 6–30). The vendor operates the team, integrating with the customer's processes. Customer's involvement deepens. Knowledge transfer happens incrementally.
- Transfer (month 30+). The team is transferred to the customer as a captive. Employees become customer employees. Facilities transfer or are renegotiated. Customer takes ownership of the operating model.
BOT contracts spell out the transfer mechanics in detail: which employees transfer, severance protections, facility transfer, IT ownership, ongoing vendor support during transition.
What a VDC is
A VDC is platform-managed indefinitely. The customer never owns the pod members; they remain platform talent. The customer doesn't take over operations at any planned future date; the platform owns operational governance for the engagement's duration.
The model assumption: you want sustained delivery capacity without taking on the long-term ownership burden of a captive team. You want flexibility to scale capacity up, down, or off without managing the HR cycle of a captive.
The single deciding factor
Does ownership of the team produce strategic value?
If yes — the team itself is part of your competitive moat, the institutional knowledge accumulating in their heads matters strategically, and you have the operational maturity to run a captive 5+ years out — then BOT (or just building a captive directly) is the right structural answer.
If no — the work matters but the team identity doesn't, the institutional knowledge can live in the codebase rather than in specific employees, and you don't want to be running an HR cycle for offshore staff in 5 years — then VDC is the better fit.
Most mid-market enterprises fall into the "no" category. They want delivery, not team ownership. BOT's transfer phase delivers something they don't actually want.
The hidden cost of BOT
BOT contracts have transfer clauses that look free at signing and turn out expensive at execution. Three categories of cost:
- Severance and retention costs. Some employees may not want to transfer. Some are not retained by the customer. Severance, retention bonuses, transition payments — all add up.
- Facility takeover costs. If the facility doesn't transfer cleanly (lease terms, IT infrastructure, country-specific employment law), there are renegotiation costs.
- Operating-model takeover costs. Once the customer owns the team, they own the HR function for it. Recruiting future hires, performance management, payroll administration, regulatory compliance for that geography. The capex of operations is permanent from transfer onward.
For comparison, a VDC has none of these. The platform handles HR, facilities, recruiting, regulatory ongoing. The customer's operational footprint stays at the engagement layer.
Decision matrix
| Scenario | BOT | VDC |
|---|---|---|
| Want to own a captive team in 2–3 years | Strong fit | Wrong model |
| Want delivery capacity without long-term ownership | Wrong model (transfer phase wasted) | Strong fit |
| Have operational maturity for offshore HR | Adequate | Adequate (don't need it) |
| Want capex amortization over 5+ years | BOT works at scale | Opex-only model |
| Want flexibility to wind down at any milestone | Wrong (locked in) | Strong fit |
| Engagement is sub-2-year | Wrong (transfer phase doesn't trigger) | Strong fit |
| Strategic IP retained in team-not-codebase | BOT preserves this | VDC requires codebase-encoding |
The BOT-to-VDC transition
Some enterprises that started BOT contracts mid-2010s are now reconsidering at the transfer phase. Common pattern:
- BOT was signed when offshore captives were the dominant model.
- Operate phase ran 2–3 years. The work matters but the team identity hasn't become strategic.
- At transfer phase, the customer realizes they don't actually want to run an offshore captive. The HR cycle, facilities, regulatory compliance are all overhead they hadn't fully priced.
- They're now evaluating: complete the transfer (commit to captive ownership), let the contract terminate without transfer (lose the team), or convert to a VDC arrangement (different operating model, same delivery shape).
The third option is increasingly common. The work transitions to a VDC pod that ramps on the codebase the BOT team built. Some BOT team members may join the VDC platform; most don't. The customer stops owning the operational layer.
Where BOT genuinely wins
To stay honest:
- Long-term strategic captive intent. You've decided you want a captive in 5+ years; BOT lowers the upfront capex of getting there.
- Specific geographic strategic value. Establishing presence in a new market where the captive team is part of your in-country footprint. BOT builds that presence with vendor cushioning.
- Regulated industries with onshore-team requirements. Where the regulatory environment requires captive-style ownership rather than platform-managed delivery.
For most mid-market engineering capacity needs, none of these apply. VDC is the cleaner fit.
Frequently asked questions
If we have a BOT engagement mid-flight, should we switch to VDC?
Depends on the phase and your forward intent. If you're in the build phase and not committed to ownership, evaluating a switch is reasonable. If you're in operate phase and approaching transfer, the question is whether to complete or convert. Mid-flight switches require planning but are doable.
What about the offshore staff who came up under BOT — what happens to them in a VDC transition?
Most don't transition. The VDC platform has its own bench. Some BOT staff may join the platform if there's mutual fit, but it's not automatic. This is the ownership-transfer cost showing up in human terms.
Can VDC be structured to behave like BOT — eventual transfer to captive?
Some platforms offer "transition to captive" clauses. Worth evaluating but rare in practice. The platform's economics are built around platform-retained talent; transition clauses break that model.
How does BOT compare to GCC standup directly?
BOT is a slower, lower-capex path to a GCC. Direct GCC standup is faster but riskier. See VDC vs GCC for the captive-vs-managed comparison.
Where to start
If you're considering a new BOT engagement, the first question to honestly answer is: do you want to own this team in 3 years? If the answer is "we're not sure" or "probably not," BOT may be the wrong shape and a VDC arrangement fits better.
To talk through the BOT vs VDC fit for a specific scenario, schedule a 30-minute call. For the broader captive-vs-managed context, see VDC vs GCC and VDC vs ODC.