Build-Operate-Transfer, almost always shortened to BOT, is a way to set up a permanent team in another country without starting a company there first. A partner builds the team, runs it as a going concern, and hands it over once you're ready to own it. The three words are the three phases, in that order.

That much is uncontroversial. The part worth understanding before you sign anything is that the phrase was borrowed from a completely different industry, where the money moves the other way, and some of the assumptions came along with it.

What does Build-Operate-Transfer mean?

Build-Operate-Transfer means a partner sets up an operation on your behalf, runs it until it's stable, and then transfers it to you. In technology it describes building a product or engineering team abroad: the partner recruits and employs the people, delivers with them, and later moves them onto your payroll and into your legal entity.

The definition matters less than the sequencing, which is the whole point of the model. You commit capital and legal exposure in stages rather than all at once, and you see the team work before you own the cost of employing it. Every other property of BOT follows from that.

Two things it isn't. It isn't a staffing arrangement, because the partner is accountable for delivery rather than for placement. And it isn't a permanent outsourcing relationship, because it's designed with an ending available. Whether you take that ending is your call.

Where the term comes from, and why the technology version is different

BOT started in infrastructure, not software. The World Bank's definition is a concession: a public authority grants a private company the right to develop and operate a facility for a fixed project period, during which the company finances, owns and runs it commercially, after which the facility transfers to the authority. Those concessions typically last 25 to 30 years, long enough to amortize the initial investment.

Read that next to the technology version and the economics invert. An infrastructure BOT is a financing structure: the private party puts up the capital, earns it back from users over decades, and hands over an asset at the end without further payment. A technology BOT is a capability structure: there's no meaningful capital asset, the term is measured in years rather than decades, and at transfer the client pays.

Deloitte's framing of the technology version is a service provider, usually based in the destination country, doing the work to set up and operationalize a Global In-house Center, which the client then assumes, typically for a fee. Deloitte also splits the history into two waves: a mid-2000s wave driven by market entry and labor cost, and the current one driven by access to talent.

So the same three words describe two arrangements with opposite cash flows. If a proposal reads as though it were built on the infrastructure model, where handover is automatic and free, that's worth a question.

How do the three phases of Build-Operate-Transfer work?

Three phases, and in a well-structured agreement only the first is a firm commitment. The partner assembles a team and delivery starts. Your local entity gets set up while that team keeps shipping, and then you hire the people you want, on your timing.

Each phase should have an exit rather than an obligation to continue.

Build

The partner recruits, employs and onboards the team, and work starts. You have no local entity, no local employment contracts and no office. The partner carries the delivery accountability, which means an underperforming team is the partner's problem to fix rather than a staffing complaint to escalate.

This is where providers differ most, and it's rarely in the contract. A traditional BOT build phase is a recruitment drive with your name on it, hiring a team from scratch in a market you don't know. The alternative is a squad drawn from a team that already exists and already works together.

We run the build phase out of Porto, where our AI-native Digital Product Studio keeps a standing team of 70 plus, which is why a squad is typically operational in four to eight weeks rather than in a hiring cycle. It also means we're not assigning people to your project: the squad works as an extension of your team, challenges decisions, and owns outcomes rather than output.

Operate

The team keeps delivering while you put the permanent structure in place: the legal entity, payroll, accounting, tax and whatever employment infrastructure the country requires. The division that confuses buyers is worth stating plainly: you own the entity and the decisions, the partner owns the delivery.

Deloitte describes the goal of this phase as reaching a steady state, with standardized procedures and service levels holding while the operation stabilizes. In practice it's also the phase where the handover either becomes possible or quietly stops being possible, depending on whether someone documents the knowledge as it's created.

Whether a partner helps here is a fair question to ask, because setting up in an unfamiliar jurisdiction is mostly a problem of knowing who to call. In Portugal we introduce clients to the people we work with ourselves: Fresh, beTaxed, Redbridge, AGPC and Porto City Council. You contract them directly. We don't take a cut and we don't sit in the middle.

The test of this phase is whether anything slows down while it happens. It shouldn't. You're establishing operations and hiring, we're still shipping, and there's no productivity gap between the two.

Transfer

You hire the people directly and the operation moves to you. What should move with them is the working knowledge: the codebase, the reasoning behind the decisions in it, and the way the team runs. That last part is the one companies undervalue. A team that has been building with AI-native workflows since its first sprint hands over practices that are harder to hire for than any individual on it.

The terms here are what separate a real transfer option from a decorative one, and they're specific enough to be worth reading side by side with any proposal. Which ones to check, and how ours are written, is the section below on what a BOT agreement covers.

Build-Operate-Transfer examples

The public record on completed transfers is thinner than the amount written about the model suggests, for a straightforward reason: a transfer is a private transaction with no disclosure obligation. The examples that exist in public are the ones where the client volunteered them or a listed provider had to file them.

Aviva, with EXL, WNS and 24/7 Customer (India and Sri Lanka, 2006 to 2008). This is the best-documented case there is, and Aviva used the term itself. Its 2006 announcement of the move of more than 5,000 vendor staff onto its own offshore division says the BOT contracts with those partners had let it ramp up rapidly, and it names the mechanism: special purpose vehicles created specifically so they could be transferred. Bangalore completed first, then Colombo and Pune. EXL's filings confirm the commercial detail from the other side, including the price basis.

Then the part most write-ups leave out. In July 2008, the same month one of those transfers completed, Aviva sold the entire captive operation to WNS for $228 million, bundled with a services contract back to Aviva. Build, operate, transfer, then sell. The transfer worked exactly as designed, and owning the team still turned out not to be the destination. That's a useful thing to know before you treat the handover as the goal rather than as one option.

Infosys and Truist Financial (Hyderabad, reported March 2026). A deal reported at more than $500 million, scaling toward roughly 4,500 people, explicitly on a BOT structure, with Infosys building and operating the center for five years before ownership and operations move to Truist. It has been reported consistently across Indian business press rather than confirmed in a release from either company, so treat the five-year term as reported rather than documented. It's the clearest current example of the model at scale.

One thing the enterprise scale of those examples hides: the mechanics don't change with headcount. The same option structure, the same net asset value basis and the same statutory transfer rules apply to a squad of 25 as to a center of 5,000.

Our own position, said plainly: we run the build and operate phases today and the transfer terms are contractual rather than demonstrated. UJET, a US cloud contact center company, partnered with us in March 2025 and launched Portugal operations that September, growing from four people to 25 across multiple dedicated product teams that may migrate to a UJET entity in Portugal.

Releases moved from monthly, with a two-week regression cycle, to twice a week. Onboarding a new team member got four times faster.

"Pixelmatters was the type of firm that would not let their team fail a client. They had that sense of ownership and accountability and wanted to understand the broader strategy and the implications of success versus failure."
Leslie Blanke, Chief Product Officer, UJET

What does a Build-Operate-Transfer agreement cover?

A BOT agreement is mostly about the third phase, because the first two are ordinary services terms. What it needs to settle is narrow: whether you can take the team, when, how many of them, and what stops when you do. Seven questions get you most of the way, and the answers matter more than the length of the contract.

Read that list against a proposal and the vague ones stand out fast. The commercially convenient outcome for any partner is that you stay a client forever, so the third phase is the one that gets written loosely.

How we write those terms

Ours, and these are contractual rather than yet exercised:

• A twelve-month minimum on the build phase, at a minimum 30 percent off our standard rates

• Pre-agreed employment transition windows after the first year. No forced handovers and no rushed timelines, because the timing is yours

• Selective hiring, so you take the people you want and the rest stay with us

• No management fee once the team is yours, and no ongoing charge on your own people

• Knowledge transfer as a structured deliverable rather than a meeting

• Capacity that scales up or down deliberately within an engagement baseline, rather than a headcount you have to renegotiate

• Moves to your entity made with each person's individual consent and in line with local law, bundled so the employer change is smooth

• You own the product, the code and the intellectual property from the first commit, so nothing about ownership changes at transfer

• If you decide against Portugal, the engagement ends at the term and you leave without an entity, without having hired anyone and without a redundancy bill

One difference worth naming, because it removes most of the machinery people associate with BOT. In the enterprise version the provider builds and holds a legal entity that the client later buys back, which is why those deals involve special purpose vehicles, share purchases and a valuation at handover. Aviva bought the shares of three of them.

We don't hold an entity. You open your own during the operate phase, so there's nothing of yours on our balance sheet and no purchase price to negotiate at the end. Fewer moving parts, and one less thing that can stall.

Two things to be skeptical about when you read anyone's terms. Transfer fees quoted as a percentage of annual run cost or as a per-head figure are common in provider material and we couldn't source them to anything credible. The same goes for the widely repeated numbers on knowledge transfer windows and non-solicit periods. Ask where a figure comes from.

Build-Operate-Transfer, BOOT, offshore development center and GCC: what's the difference?

People use these four terms as though they were interchangeable, and they describe different things. Two of them are structures, one is a destination and one is mostly a synonym.

Worth knowing on each. An offshore development center is a destination, and BOT is one way to reach it. You can also build one directly, and if you've hired in that country before, that's usually the cheaper route.

GCC is what analysts now call the same construct: Deloitte still writes Global In-house Center, while nasscom, Zinnov and Everest Group have settled on Global Capability Center.

When is Build-Operate-Transfer the right model, and when isn't it?

BOT earns its place when you want a permanent team in another country but aren't ready to bet a legal entity on that country before you've watched the team work. If that sentence doesn't describe you, one of the simpler models probably fits better.

It fits when:

• You expect to employ people in that country within a couple of years, and you'd rather find out whether the market works before you incorporate

• You need a cross-functional product team rather than a single discipline

• The capability is permanent, not a gap with an end date

• Your planning horizon is longer than the minimum commitment, which is usually twelve months

It's the wrong instrument when:

• You'll never employ anyone locally. You'd be paying a premium for an exit you won't take

• You need capacity this month. Staff augmentation starts in days

• The work is one role. One Android developer doesn't need a transfer structure around them

• Your product direction changes every quarter

• You already know the market and have hired in it. Opening your own entity skips a step you'd be paying for

BOT also isn't the cheap option, and any provider who tells you otherwise is selling you the version without a real transfer in it. It costs more than renting capacity and less than incorporating before you know whether the market works. What the difference buys is the ability to stage the commitment.

With us a Tech Hub on this model starts at €400k a year, which is a different order of spend from bringing in two engineers, and should be, because you're buying a team rather than hours. For how it compares with the alternatives, we've written about Staff Augmentation, Managed Services and Build-Operate-Transfer side by side, and the full terms sit on our Build-Operate-Transfer page.

What goes wrong with Build-Operate-Transfer?

Four failure modes show up in the analyst record, and none of them are about bad intentions.

The center ends up shaped like the provider rather than like you. HFS Research put it well in May 2026: the risk is that the operating model starts to mirror the provider's delivery model rather than the enterprise's long-term ownership goals. You inherit something built to be run by someone else.

Most of that traces back to incentives. A partner paid to grow headcount and bill hours will build an operation that needs the partner in it.

We build hubs, not headcount, and the engagement is priced on product impact at velocity rather than on capacity, so there's nothing to protect by keeping the operation dependent on us. The team also sits inside your organization rather than behind us, which means what gets built is your way of working with our standards in it. And we take responsibility for the team's performance while we run it, so when something isn't working, whether that's team composition, velocity or collaboration, we raise it early and propose a fix rather than waiting to be asked. The model depends on long-term trust rather than on locking anyone in.

The knowledge sits in too few heads. If one person holds the context, transfer becomes a formality and what you inherit is a risk. More than one person deep on every part of the system is the fix, which makes this a process problem rather than a goodwill one. Decisions written down while they're fresh, and handover treated as a deliverable rather than a meeting.

People leave at the handover. Zinnov's 2026 research across more than 95 GCCs puts overall attrition at 16 percent and high-performer attrition at 16.5 percent, driven by skill stagnation and limited growth exposure rather than pay. People decide whether to join you based on how you handle the transfer, and the first conversation about their future shouldn't be an offer letter. Pre-agreed transition windows help, because they make that conversation scheduled rather than a surprise.

Owning it turns out not to be what you wanted. Everest Group data reported by CIO records 452 new captive centers established in 2023, and more than 50 companies divesting captives between 2020 and 2023. Aviva is in that pattern. The lesson isn't that the model fails, it's that the transfer is a decision to make at the time rather than a conclusion to assume at the start.

Transfer is a decision, not a deadline

Build and operate are the phases you'll spend the most time in, and they're the ones every provider can describe. Transfer is where the agreements differ, and it's the letter that's easiest to write vaguely, because the commercially convenient outcome for a partner is that you stay a client forever.

So read the third phase first, and read it as an option rather than as a plan. A model whose entire value is the option to own the team is worth exactly as much as the specificity of that option, and no more. Ours is written to be exercised on your timing or not at all: pre-agreed windows, selective hiring, each move made with the person's consent, and billing that stops when the team becomes yours.

The option is the thing to buy, in other words, rather than the handover itself. Aviva completed one and decided within two years that it didn't want what it had taken, while Truist has five years before it has to decide anything at all. Both of those are the model working as designed.

Which makes it a strange thing to build, on the face of it. We spend a year assembling a team you'd struggle to replace and then hand you the means to employ it without us. That only stops being strange once you accept that the dependency was never the product. We build hubs, not headcount, so a squad that becomes your in-house team is the work finishing properly rather than revenue walking out of the door.

The providers worth talking to are the ones who write the option down in specifics before you ask, and who would rather keep you by being worth keeping than by making leaving expensive.