Most outsourcing conversations start with a question about capacity: how many engineers, at what cost, starting when. The Build-Operate-Transfer model starts with a different question entirely: do you eventually want to own this team?
If the answer is yes, BOT changes the entire structure of the conversation.
What BOT Actually Means
Build-Operate-Transfer is a three-phase engagement model:
Build: The partner recruits, sets up, and structures the team from scratch. This includes hiring the right engineers for your stack, establishing tooling and infrastructure, defining processes, and setting up the operational framework the team will run on. The client is closely involved in team design and selection, but the partner handles the operational setup.
Operate: The partner runs the team for a defined period, typically 12 to 36 months, under agreed performance benchmarks. During this phase, the team is delivering real work on the client’s roadmap, not just warming up. The partner is also intentionally building the team’s capability and documentation to a state that’s ready for transfer.
Transfer: At an agreed milestone, full ownership passes to the client. This includes the people (employment relationships), the processes, the tooling, the institutional knowledge, and in most structured BOT engagements, the legal entity itself if one was set up in-country.
The key distinction from every other engagement model: the end state is the client owning a fully operational offshore team, not a continuous outsourcing relationship.
Deloitte’s Global Outsourcing Survey confirms this isn’t a niche approach: organizations are increasingly adopting Build, Operate, Transform, and Transfer models specifically to streamline how in-house engineering capability gets built, reflecting a broader shift toward insourcing and owned capability rather than indefinite outsourcing relationships.
Who BOT Is Built For
BOT tends to fit a specific profile better than it fits everyone. The clearest fits:
Companies with a defined long-term offshore strategy. If the three to five year plan includes a permanent offshore engineering presence, BOT is usually more efficient than building it directly from day one. The setup complexity, entity formation, local hiring law, HR infrastructure, and operational overhead of standing up a Vietnam-based engineering team from scratch is significant. BOT transfers that complexity to a partner who’s done it before, while the client retains the option to own the result.
Companies who’ve rejected outsourcing on principle before. “We want to own our team eventually” is one of the most common reasons mid-market companies don’t outsource even when the economics would otherwise work. BOT is specifically designed for that concern, because the model’s entire structure is oriented toward the client eventually owning what gets built.
PE-backed portfolio companies with a defined investment horizon. For a company that’s going to be sold or scaled significantly in three to five years, a BOT arrangement can build offshore capability that becomes a permanent structural cost advantage, either retained post-exit or surfaced as an operational asset during due diligence.
Companies scaling past the point where a standard ODC is still the right model. An ODC engagement keeps the outsourcing relationship indefinitely. BOT is the natural next step for a company that started with an ODC and wants to move toward ownership rather than continuing to pay an ongoing management premium.
What Makes BOT Different From an ODC
Both models involve a dedicated team working on the client’s product over an extended period. The differences that matter:
The end state is designed in from the beginning. An ODC can theoretically be converted to a client-owned team, but it usually requires renegotiation, legal entity work, and transition planning that wasn’t built into the original engagement. BOT builds transfer-readiness into every phase from day one, which means the actual transfer is an expected event, not a difficult renegotiation.
Documentation and process ownership are different. In a standard ODC, the partner owns the operational processes. In BOT, processes are explicitly designed and documented for eventual client ownership, which means more rigorous documentation habits throughout the Operate phase.
Pricing structure is different. BOT engagements typically have a higher upfront cost in the Build phase (reflecting entity setup, recruitment, infrastructure, and operational design) and may include a transfer fee at the end. The relevant comparison isn’t BOT versus ODC per month, it’s total cost of ownership over the full engagement versus the cost of building and running the equivalent team directly from day one.
The Transfer Milestone: The Part That Actually Needs to Be Specific
The most common BOT failure mode isn’t in the Build or Operate phases. It’s a transfer milestone that was described in principle but never defined in the contract.
“We’ll transfer when the team is ready” is not a BOT contract. The following need to be specific and written before the Build phase starts:
What transfers: people (employment relationships and HR obligations), processes (documented workflows, runbooks, and operational procedures), tooling (licenses, infrastructure access, and any proprietary systems), and legal entity (if a local subsidiary was set up, what happens to it).
When transfer happens: tied to a specific date, a specific team size, a specific performance benchmark, or some combination of the three. Ambiguity here tends to drift in whoever’s favor is more convenient at the time.
What the client takes on at transfer: employment law obligations, payroll, HR administration, ongoing infrastructure costs, and operational management. These aren’t surprises, but they need to be planned for, not discovered on transfer day.
What happens if the client isn’t ready at the agreed milestone: does the Operate phase extend, at what cost, under what terms?
Getting these answers before signing is the difference between a BOT engagement that delivers its intended end state and one that stays in the Operate phase indefinitely because the transfer was never actually defined.
The Honest Tradeoffs
BOT is not the right model for every company, and it’s worth being direct about where it doesn’t fit.
It requires a longer planning horizon than most engagements. If the business need is capacity in the next 90 days, BOT’s Build phase timeline doesn’t fit that urgency. A standard ODC or project-based engagement fits better.
It requires genuine commitment to eventual ownership. BOT is a poor fit if “we want to own it eventually” is aspirational rather than genuinely planned. The model is optimized for a specific end state, and if that end state isn’t real, a simpler ODC delivers the same interim value without the setup overhead.
It requires the client to plan for what ownership actually means operationally. A transferred team is the client’s operational responsibility from day one of ownership. HR, payroll, performance management, and local employment law all become the client’s problem. That’s the whole point, but it needs to be resourced for before transfer day, not after.
Questions Worth Asking Before a BOT Conversation
- Is permanent offshore ownership genuinely in the plan, or is it just something that sounds appealing in the abstract?
- What’s the realistic timeline before the client is ready to operate the team independently?
- Who in the client organization will own the team post-transfer, and are they already identified?
- Does the partner have a track record of completed BOT transfers, not just BOT engagements in progress?
The last question matters more than most buyers ask it. A partner with BOT clients in the Build and Operate phases is common. A partner with completed, documented, client-owned transfers is a shorter list.
Frequently Asked Questions
What does Build-Operate-Transfer actually mean in offshore software development? It’s a three-phase engagement: a partner builds a dedicated team from scratch, operates it for a defined period against agreed benchmarks, then transfers full ownership, people, processes, and infrastructure, to the client at an agreed milestone.
How is BOT different from a standard dedicated team (ODC)? An ODC continues indefinitely as an outsourcing relationship. BOT is designed around a defined end state: the client eventually owns the team outright. Transfer-readiness is built into the process from day one, rather than negotiated after the fact.
What’s the biggest risk in a BOT engagement? A transfer milestone that’s described only in principle, not specified contractually. What transfers, when, and what happens if the client isn’t ready all need to be defined before the Build phase starts.
Is BOT more expensive than a standard ODC? Upfront, usually yes, since it involves entity setup and transfer-ready process design. Over the full engagement, total cost is often lower than building the equivalent team locally from scratch, which is the more relevant comparison.
Related Reading
- ODC, Managed Service, Project-Based, and BOT: How to Choose the Right Engagement Model
- How Much Does an ODC Engagement Cost?
- A Mid-Market Buyer’s Guide to Offshore Engineering Partners in 2026
If BOT is something the business is genuinely considering, a scoping call is a useful place to pressure-test whether the timing and planning horizon actually fit the model, before committing to it.
