What Is Build-Operate-Transfer (BOT)? Cost and Risks

Share in
05-11-2026

Building a software team in another country used to mean two blunt choices: outsource the work or open your own legal entity. Build-operate-transfer (BOT) sits between them, and the market has quietly renamed it. Legal advisors, including Morgan Lewis now frame it differently. They list it as one of the models companies use to stand up a Global Capability Center (GCC). That's the term that has replaced "captive offshore unit" in enterprise sourcing conversations since 2024. That reframing changes what you should be negotiating for: not a smoother handover, but a cleaner acquisition.

This article covers what a BOT deal actually transfers and why public timeline estimates can differ by as much as 24x. It also covers what BOT really costs and the team-size threshold below which it stops paying for itself.

Back to top

What is the build-operate-transfer (BOT) model?

Ownership transfer journey from Build to Operate to Transfer, showing ownership shifting from the provider to the buyer

A build-operate-transfer arrangement is a contract in which a provider hires people, builds infrastructure, and runs a technical team in another country on your behalf. At an agreed point, the provider transfers the whole operation to you, and you end up owning what was, until then, someone else's operation. BOT is a staged acquisition paid for in installments, not a richer outsourcing package.

Every top-ranking page on this keyword defines BOT through its three phases: build, operate, and transfer. This article does the same to match how people search. What most of them skip is what "transfer" actually hands you, covered below.

The term to know alongside BOT is Global Capability Center (GCC). Morgan Lewis and Torry Harris now frame nearly all BOT content around GCC rather than treating BOT as a standalone concept. A company setting up a GCC abroad increasingly treats BOT as one of the most practical ways to start. If your organization is researching offshore delivery models, BOT, and GCC aren't separate searches anymore. They're the same conversation from two different entry points.

BOT in software versus BOT in infrastructure and PPP

The same three letters describe two different deals. In infrastructure and public-private partnerships, BOT transfers a physical asset (a toll road, a power plant) and the right to operate it. In software and IT services, BOT transfers a company and a team instead: people, contracts, and intellectual property. This piece covers the software and IT delivery version only.

What you actually own at the end of a BOT contract

Five items that must transfer by name in a BOT deal: legal entity, employment contracts, source code ownership, tools and licenses, system documentation

BOT deals structure the transfer in three ways. Asset-based means you buy the equipment and IP, but the provider's local entity keeps existing. Entity-based means the provider sets up a legal entity that becomes yours. Joint venture means you and the provider co-own the entity for a period before full transfer. Which structure a contract uses changes what "transfer" legally means, so confirm it before signing.

Whatever the structure, five things need to change hands by name:

  • The legal entity, if the structure is entity-based, including its registration, licenses, and bank accounts.
  • Employment contracts, so engineers become your employees under local law, not the provider's.
  • Source code ownership, transferred explicitly, not assumed to follow the team.
  • Tools and software licenses the team depends on daily.
  • System documentation, covering architecture, runbooks, and operational knowledge, not just code comments.

Every one of the top five ranking pages on this keyword describes the transfer phase in general terms without listing what specifically changes hands. Contracts that just say "the team transfers" without naming these five items are where disputes start. Those disputes usually surface months later, when someone asks who owns a repository or a support contract.

Back to top

How the build-operate-transfer model works, phase by phase

Public timelines for BOT disagree sharply. No top-ranking page explains why before quoting a number. The table below lines up estimates from the three sources with the most specific figures:

Phase

Saigon Technology

ttpsc

Coderslink

Spread

Build

6-8 weeks

1-3 months

3-6 months

~4x

Operate

2-6 months to stabilize, 6-24 months to prepare transfer

2+ years

18-48 months

~24x

Transfer

4-12 weeks

3-6 months

1-6 months

~6x

Two of the five top-ranking pages give no timeline figures at all. Where the three above cite ranges, the gap between the low and high end runs from four times (Build) to twenty-four times (Operate).

That spread isn't inconsistent data. It's inconsistent measurement. Each source starts and stops the clock at a different milestone. Some measure the build from signed contract to first hire, others to a fully staffed team. Some measures operate until the team is functionally stable. Others measure it until it's contractually ready for transfer, a much later and fuzzier bar.

ttpsc adds a detail none of the others quantify. Build duration depends heavily on team size: around one month for a team under five people, two to three months for a team over fifty. Team size, not process maturity, is the real driver behind the build-phase spread. It's also the one variable you can plan around.

Duration alone doesn't tell you what to check for. The table below sets out what happens in each phase:

Phase

What happens

Completion milestone

Typical duration

Who owns what after

What slows it down?

Build

Design the operating model, hire and onboard the first team, and set up infrastructure and security

The team is staffed and delivering against a defined scope

6 weeks to 6 months (see spread above)

The provider owns the entity and employment contracts.

Team size, local hiring market, infrastructure complexity

Operate

Stabilize delivery, transfer knowledge gradually, and build a local management layer

The team meets agreed delivery and readiness criteria for transfer.

2 months to 2+ years (see spread above)

The provider still owns the entity; you own the roadmap.

Whether a local manager was hired early or only at transfer time

Transfer

Move the entity, employment contracts, assets, and documentation.

All five transfer items (above) are legally reassigned.

4 weeks to 6 months (see spread above)

You own the entity, contracts, and IP.

Certification scope, contract renegotiation, disputed asset ownership

Phase 1: Build

Build means designing how the team will operate, hiring and onboarding the first cohort, setting up infrastructure, and setting security baselines. It's not just posting job listings. GMO-Z.com RUNSYSTEM has run this exact build-and-operate cycle four times. New delivery centers opened in Tokyo (2007), Ho Chi Minh City (2008), Da Nang (2012), and Hue (2023). Each one followed the same sequence: legal setup, hiring, infrastructure, and security certification, all completed before the center took on delivery work. That sequence is a useful reference point for what "build" actually includes beyond recruiting.

Phase 2: Operate

Operate is where delivery stabilizes, knowledge transfers gradually, and a local management layer gets built that will take over after transfer. That last part matters most. The common mistake is treating this phase purely as a delivery period. Companies only start looking for that local manager once the transfer is already on the calendar. By then, you're hiring a manager into a team that's used to reporting to someone else. Adoption slows, and the odds the manager doesn't stick go up.

Operate is also where the 24x timeline spread shows up. Some vendors measure it from the point the team is functionally running. Others measure it to the point it's contractually ready to transfer. That readiness bar requires a stable local manager, documented processes, and often a specific retention track record. Ask any vendor which milestone they mean before comparing quotes.

Phase 3: Transfer

Transfer moves the entity, employment contracts, assets, and documentation to you. Duration runs 4 to 12 weeks according to the lowest estimate, but 3 to 6 months according to the highest.

Before transfer completes, the contract should define exact readiness conditions: documented processes, a functioning local manager, and a retention track record. It should also define what happens if the team hasn't met them by the target date. Does the operation phase extend? Who pays for that extension?

Back to top

Why companies choose BOT over outsourcing, an ODC, or their own entity

Who carries hiring and delivery risk over time across outsourcing, an ODC, BOT, and setting up your own entity, with risk shifting to the buyer at the BOT transfer point

You're choosing between outsourcing, an offshore delivery center (ODC), BOT, and setting up your own entity. Really, you're choosing between four risk allocations, not four service tiers. Four of the five top-ranking pages compare them by feature instead ("more flexible," "more control"). That doesn't tell you when to pick which. Compare them by threshold and exit cost instead:

Option

Upfront cost

Time to first hire

Who bears hiring risk

Who bears delivery risk

Cost to exit

When it wins

Project-based outsourcing

Low

Days to weeks

Provider

Provider

Low, cancel the contract

Short, well-defined scope

Offshore delivery center (ODC)

Low to moderate

Weeks

Provider

Shared

Low to moderate

Ongoing work, no need to own the entity

Build-operatee-transfer

Moderate to high

Weeks

Provider, until transfer

Shared, then yours

High after transfer, low before

You want ownership but not year-one hiring risk

Own legal entity

High

Months

You

You

High, entity wind-down

Long-term core capability, full control needed

Ownership without the first year of risk

BOT gives you your own company and team without carrying the hiring risk and legal risk of year one. That claim holds only with a clear cancellation clause for the transfer itself. Skip that clause, and the risk doesn't disappear. It just gets deferred to the transfer date.

Faster entry, and a team built for you

You get people working within weeks instead of waiting months for entity registration. That's true only where the provider already has an established entity and recruiting pipeline. In a new market, BOT takes just as long to start as building your own operation would. What's different from standard outsourcing is that people are recruited against your criteria from day one, specifically so the team is transferable later. GMO-Z.com RUNSYSTEM's own history includes a real ownership transfer, not a hypothetical one. The company joined the GMO Internet Group in 2011, a change of ownership that shaped how it thinks about transferable teams today.

Back to top

How much does the BOT model cost?

Iceberg diagram showing the visible engineering rate above the waterline and hidden BOT cost layers below it: entity setup, retention bonuses, knowledge-transfer costs, and employer statutory contributions

None of the top five ranking pages on this keyword publish a cost breakdown. The TTPSC claims BOT saves "up to 60%" against "the usual cost." Botulinum America claims it can "cut IT costs by 20-30%." Neither states whether that figure includes the full loaded cost. Neither cites a source or shows the calculation. That's why a line-item cost table is more trustworthy:

Cost item

Payment structure

Fixed or scaled with headcount

Which phase, who pays?

Entity setup and legal fees

One-time

Fixed

Transfer, buyer

Local payroll system setup

One-time

Fixed

Operate to transfer, provider then buyer

Retention bonuses at transfer

One-time

Scales with headcount

Transfer, negotiated

Knowledge-transfer costs

One-time

Scales with team complexity

Operate to transfer, shared

Duplicate management during handover

Recurring, temporary

Fixed

Transfer, negotiated

Legal and advisory fees

One-time

Fixed

Transfer, buyer

Employer statutory contributions

Recurring, ongoing

Scales with headcount

Post-transfer, buyer, permanently

BOT carries cost items a standard per-engineer rate doesn't. These include entity setup and standing up a local payroll system. They also include retention bonuses timed to the transfer, knowledge-transfer costs, duplicate management overhead during handover, and legal and advisory fees. They sit on top of engineering cost, not inside it. That's why a straight hourly-rate comparison undersells what BOT costs in year one.

The single largest cost you inherit permanently is the employer's mandatory statutory contribution. It varies by up to 16 times depending on the country. Figures below reflect 2026 published rates. Romania sits at 2.25%. The United States runs roughly 8-15%, depending on the state. That figure combines FICA (the payroll tax funding Social Security and Medicare) at 7.65% and FUTA (the federal unemployment tax) at 0.6%. It also includes a variable state unemployment tax. The Philippines runs around 14%, combined across SSS (the state social security fund), PhilHealth (public health insurance), and Pag-IBIG (a mandatory housing fund). India runs 12% EPF (Employee Provident Fund, a mandatory retirement savings scheme). Vietnam runs 21.5%. Poland runs up to 22.14% under the ZUS system (the state social insurance institution). Mexico runs roughly 30-40%, and Brazil 28-36%.

This figure matters more for BOT than for other delivery models because of when the liability lands on you. Under standard outsourcing, that contribution is baked into the provider's rate, and you can exit by canceling the contract. Once the transfer is complete, it becomes your own statutory obligation. It's payable for as long as you employ that team, with no contract to cancel out of.

Two sources are worth anchoring your budget to. Use the Accelerance 2026. Global Software Development Rates & Trends Guide for regional hourly rate ranges. Use the Stack Overflow Developer Survey 2025 for developer salary benchmarks by country.

Back to top

Best countries for a build-operate-transfer entity

Map marking six countries worth scoring for a BOT entity: Vietnam, India, the Philippines, Poland, Romania, and Mexico

None of the top five ranking pages compares countries for entity placement. That's a real gap. Three of the five sources are themselves based in different countries: Poland, Vietnam, Mexico. Fixed transfer cost is what a country comparison should actually score on:

Country

Entity setup cost and time

Employer statutory contribution

Talent pool size

Employment contracts transfer automatically?

Wind-down cost if you exit

India

Moderate, 4-6 weeks

12% EPF

Very large

No, it requires re-signing.

Moderate

Vietnam

Low, 3-4 weeks

21.5%

530,000-600,000 developers

No, it requires re-signing.

Low to moderate

Philippines

Low, 3-5 weeks

~14% (SSS, PhilHealth, Pag-IBIG)

Large

No, requires re-signing.

Low

Poland

Moderate, 4-8 weeks

Up to 22.14% ZUS

Large, EU-integrated

Yes, under EU transfer-of-undertakings rules

Moderate to high

Romania

Moderate, 4-6 weeks

2.25%

Moderate

Yes, under EU transfer-of-undertakings rules

Moderate

Mexico

Moderate, 4-8 weeks

~30-40%

Large, growing

No, requires re-signing.

Moderate

Score countries on three things you can verify, not on adjectives: talent pool size, mandatory contribution rate, and the procedure for transferring business ownership. Vietnam also adds 50,000-60,000 new IT graduates a year, on top of the figures in the table above.

For a BOT deal specifically, what decides the outcome isn't the hourly rate; it's the fixed cost and procedural complexity of transferring ownership.

A capability worth transferring should already meet enterprise-grade standards before it changes hands, not after. GMO-Z.com RUNSYSTEM's four delivery centers operate under the CMMI Level 3 process maturity and ISO/IEC 27001:2022 information security certification. That's the kind of baseline you should confirm exists before assuming a transferred team will meet it on day one.

Back to top

Who the build-operate-transfer model is for, and the minimum team size that makes it work

Line chart showing fixed transfer cost and ownership savings crossing at a break-even point of roughly 5 engineers

Three of the top five ranking pages on this keyword address who BOT suits, but they answer with company type. This section answers with a headcount threshold and the calculation behind it.

Three kinds of companies commonly choose BOT. Enterprises scaling engineering capacity beyond what local hiring can support are one. Companies establishing a GCC in a new country for the first time are another. The third is organizations that want long-term ownership of a delivery team without carrying first-year hiring risk.

Here's where sources disagree, and by how much. Coderslink states that "the BOT is best used in development teams of 10 or more employees." ttpsc prices a Build phase for teams under 5 people at around one month. That implicitly treats teams smaller than 5 as workable. It's a 2x gap between the two sources that actually name a threshold, and neither shows the math behind their number.

The break-even calculation resolves the disagreement, using the same cost buckets from the pricing section above. Fixed costs stay the same regardless of team size: entity setup, payroll system setup, retention bonuses, IP transfer, duplicate management, and legal fees. Variable costs scale with headcount: the cost gap between owning a team directly and outsourcing the same work, multiplied by engineer count.

The break-even point is where these two lines cross. It shifts with market salary levels, local procedural complexity, and how long you plan to run the team. Below that point, fixed costs outweigh the savings from ownership. Above it, ownership wins.

Fixed cost varies by country, so the minimum viable team size varies by country too. That's the actual reason Coderslink (Mexico-focused) and ttpsc (Poland-focused) land on different thresholds. Each is correct for the fixed-cost structure of the country they're describing. Each is also only half right as a general rule.

For most countries in the table above, the fixed cost of transferring a team outweighs the ownership savings below roughly five engineers. If your planned team is smaller than that, ask about an offshore delivery center (ODC) model instead. Revisit BOT once the headcount justifies the fixed cost.

Back to top

Key risks of the BOT model and the clauses that prevent them

Three BOT risks paired with the contract clauses that prevent them: the retention question, cost overruns in the transfer window, and losing certification scope

The second-ranked page on this keyword groups risks with the clauses that mitigate them under one heading. This article follows the same structure. Splitting them into two sections would just repeat the same information twice. All three risks are below the surface in the back half of the contract, not the build phase.

The retention question no BOT provider answers

None of the five top-ranking pages state how many engineers stay on the team after transfer or publish their own attrition rate. The second-ranked page has a dedicated section titled "Employee Retention Challenges" and mentions retention bonuses but still doesn't include a figure.

Your contract should pin down four things:

  • What percentage of engineers are still on the team 12 months after transfer.
  • Who becomes the local manager, and whether that person was hired for the role from the start.
  • Where the provider's project managers and bridge engineers go after transfer.
  • What happens if you decide not to complete the transfer at all.

For reference, industry-reported figures (self-reported by providers, not independently audited) put dedicated-team attrition at 8-12% and staff-augmentation attrition at 18-22%. Post-transfer retention doesn't fit cleanly into either bucket, and no one currently measures it, RunSystem included; it will publish that figure once it has one.

Cost overruns that only appear in the transfer window

Duplicate management, retention bonuses, and legal costs spike specifically when a transfer runs longer than planned. Sources quote transfer duration anywhere from 4 to 12 weeks up to 3 to 6 months. A contract might be priced against the low estimate while the actual transfer lands at the high end. That gap is exactly where the extra cost shows up. The clause that prevents it is a pricing formula agreed in advance, plus a clear answer to who pays for time beyond the window.

Losing certification scope when the entity changes hands

An ISO/IEC 27001 certification is issued for a specific legal entity and scope. A new owner doesn't automatically inherit it, one of the least visible risks in a BOT deal. The clause that prevents it should state explicitly what happens to the certification and its audit records at transfer.

Whether employment contracts transfer automatically also isn't uniform. The EU has transfer-of-undertakings rules that preserve employment terms. Many countries in Asia require re-signing new contracts instead. That single legal difference determines how many people actually follow the team into the new entity.

Source code ownership depends on which country's law applies, and BOT complicates it further because ownership changes hands twice. In the US, code written by employees automatically belongs to the company, but code written by contractors doesn't, unless there's a written assignment. In most civil-law countries (continental Europe, Latin America, and much of Asia), the original author retains rights until a written transfer occurs. The contract needs to specify exactly when code moves from engineer to provider. It needs to separately specify when it moves from provider to you.

Back to top

How to choose a BOT partner

Two people in a due-diligence conversation in an enterprise office setting, with a callout on the six questions that separate a real answer from a sales brochure

The second-ranked page has a section titled "Due Diligence Questions You Should Ask." Its questions are the kind a sales brochure already answers. The six questions below are different. Each asks for exactly what the research behind this article found nobody publishing, with a clear signal for a good answer versus a weak one:

  • What percentage of engineers stayed 12 months after your last transfer? A real number beats "strong retention culture."
  • What's your own attrition rate, and how do you measure it? A number and a measurement window beat "very low."
  • What's the basis for your cost-savings estimate? A calculation beats a bare percentage.
  • What's your minimum viable team size, and what's the math behind it? A break-even calculation like the one above beats a number with no reasoning.
  • When does your Operate phase start and end, exactly? Specific milestones beat "once the team is running smoothly."
  • What happens if we decide not to complete the transfer? A specific cancellation clause beats treating the question as unlikely to come up.

GMO-Z.com RUNSYSTEM can answer some of these directly today: certification scope, delivery-center history, and entity structure. Not all of them yet, particularly published retention and attrition figures. Naming that gap honestly is exactly the kind of answer this article argues you should be listening for.

Back to top

Final thought: the transfer clause that decides whether a BOT deal worked

BOT is a staged acquisition, so the transfer clause decides the outcome, not how smoothly the operation phase felt along the way. This article found three places where the market gets confident on numbers it can't back up:

  • The same phase gets timeline estimates that differ by up to 24 times across sources.
  • The only two pages that state a minimum team size disagree by a factor of two, with no calculation shown.
  • No provider currently publishes what percentage of a team stays after transfer.

If you're evaluating BOT, bring your planned headcount, target country, and timeline to a conversation. Run the break-even calculation against your own numbers rather than a vendor's rate card.

Back to top

FAQ

What is the build-operate-transfer model in software development? 

BOT is a staged acquisition. A provider builds, staffs, and runs a technical team on your behalf, then transfers the legal entity, contracts, and IP to you. It's distinct from infrastructure BOT, which transfers a physical asset and its operating rights, not a company.

How long does a BOT engagement take end to end? 

Public estimates disagree sharply by phase. Build runs 6 weeks to 6 months. Operate runs from 2 months to over 2 years. Transfer runs 4 weeks to 6 months. The exact number depends on which milestone each source measures from and to.

What is the minimum team size for BOT to make sense? 

For most countries, fixed transfer costs outweigh ownership savings below roughly 5 engineers. The exact threshold depends on the country's entity setup and statutory contribution costs; below it, consider an ODC model instead.

Is BOT better than outsourcing? 

BOT wins when you want long-term ownership without year-one hiring risk and your team size clears the break-even threshold. Outsourcing wins for shorter, well-defined scopes where you don't need to own the entity.

What happens if we decide not to complete the transfer? 

This depends entirely on the cancellation clause negotiated upfront. Without one, the deal typically continues as an extended operate arrangement, and you should confirm in advance who bears the added cost of that extension.

Back to top
Get expert tech consultation from GMO Z.com RUNSYSTEM with 20 years of experience
GMO-Z.com RUNSYSTEM