Build Operate Transfer Model: A Buyer's Guide

What is the build operate transfer model?

A build operate transfer model is an engagement where a partner builds a technology team, runs it to agreed performance, then hands over the team, tooling, process and legal entity to the client. Morgan Lewis frames this as the defining feature of BOT: build and run first, transfer second.

The appeal is straightforward. A company gets a working engineering capability without the twelve-to-eighteen month slog of setting up a foreign legal entity, hiring a leadership team from zero, and learning a new labor market by trial and error. The vendor absorbs that risk during build and operate. The client inherits a running team instead of a blank page.

That trade only pays off if the transfer actually works. Plenty don't.

How does BOT differ from an ODC or a captive GCC?

BOT sits between two other models on a spectrum of ownership. An ODC (offshore development centre) stays vendor-owned and vendor-managed for the life of the contract. A captive centre, or GCC, is client-owned from day one. Morgan Lewis describes BOT as the bridge between the two.

That framing matters when a buyer is choosing an engagement model. An ODC never asks "who owns this in three years": the vendor always does. A captive GCC never asks it either: the client always does. BOT is the only one of the three where ownership is designed to change hands, which is exactly why the contract terms governing that change deserve more scrutiny than either of the other two models requires.

The three phases of a BOT engagement

A BOT deal has three distinct phases with different risks. Each phase needs its own success criteria, not a single vague milestone at the end of the contract.

Build

Build is entity setup, hiring, tooling and initial process design, usually against a defined headcount and role mix. The vendor is doing something the client either can't do yet (no local entity, no employer-of-record relationships, no sourcing network) or doesn't want to do twice (why build hiring infrastructure for a team you're about to hand off anyway).

The risk here is subtle: a vendor under pressure to hit a hiring deadline can staff the centre with whoever is available rather than whoever the client will want to keep. Headcount targets without retention targets create exactly this incentive.

Operate

Operate is the vendor running the centre against SLAs while the client observes, audits and gradually takes on more direct interaction with the team. This phase is where trust is supposed to build between the client and the people it will eventually manage directly.

It's also where documentation debt accumulates if nobody is assigned to prevent it. A team that's shipping well under vendor management can look ready to transfer while actually running on tribal knowledge held by two or three senior people. Operate needs a documentation checkpoint, not just a delivery checkpoint.

Transfer

Transfer is the handover of people, IP, tooling licenses, vendor contracts and the legal entity itself, against pre-agreed readiness criteria rather than a calendar date. This is the phase most BOT contracts under-specify, because it's the one furthest away when the contract gets signed.

A transfer clause that says "team and assets will transfer at month 24" without defining price, retention terms and documentation standards is not a transfer clause. It's a placeholder that both sides will renegotiate under pressure later.

Why is build operate transfer gaining traction in India?

Interest in BOT and captive models in India is rising because the GCC market itself is expanding fast enough that companies are looking for lower-commitment ways to enter it. India hosts 2,117 GCCs generating $98.4 billion and employing about 2.4 million professionals in FY2026, according to the NASSCOM-Zinnov India GCC Report 2026.

That report projects over 2,500 GCCs employing 2.8 to 2.9 million people by 2030. It also found that roughly 80% of new GCCs launched in 2026 name AI and machine learning as their core mandate, which is pulling in companies that have never run an offshore engineering operation before and are using a BOT model for GCC entry rather than building from scratch.

Why Mohali is entering the conversation

Nearly a quarter of India's new GCC units in the past year went to emerging cities beyond the usual metros, Mohali among them, per the same NASSCOM-Zinnov 2026 report. In August 2026, the Government of Punjab partnered with Zinnov as State Partner at Zinnov Confluence 2026 to present Mohali as an emerging GCC hub, in a session titled "The Location Playbook: Mohali as North India's Emerging GCC Hub," according to Business Standard.

The economics behind that push are documented, not speculative. Tier-2 Indian cities typically run 10-35% lower cost of living than the nearest tier-1 hub, with attrition observed up to 10 percentage points lower, per EY India, which lists Chandigarh among the tier-2 cities already running GCC operations. Punjab's Industrial and Business Development Policy 2026 backs this with an employment subsidy of Rs 7,500 per employee per month, according to Invest Punjab.

Where do BOT contracts actually break down?

They rarely fail at build. Build is the phase every vendor knows how to price and staff, because it looks like a normal delivery project. The failures cluster at transfer, and they cluster around three specific gaps.

Transfer pricing left vague

Many BOT contracts state that assets will transfer "at fair market value" or "at cost" without defining either term. Fair market value of what: the office lease, the software licenses, the recruiting pipeline, the client relationships the team built during operate? Cost basis calculated by whom, using which vendor's books?

This ambiguity is cheap to fix at signing and expensive to fix at transfer. Put a pricing formula or a fixed transfer fee in the original contract, tied to specific line items, before either side has any incentive to negotiate it upward or downward under time pressure.

Key staff who don't move across

A BOT centre is worth transferring because of the people in it, not the desks. Vendors sometimes retain their strongest engineers for other client work and let the transferring team skew toward whoever is easiest to release, or they offer vendor-side retention bonuses that lapse the moment the transfer happens.

The fix is contractual, not aspirational: name the roles (not just headcount) that must transfer, attach retention incentives that survive past the transfer date, and give the client visibility into individual attrition during operate, not just team-level delivery metrics.

Knowledge that was never documented

A centre can hit every SLA during operate while running entirely on what two senior engineers remember. If nobody owns documentation as a deliverable, it doesn't get written, because writing it down has no effect on this quarter's delivery numbers.

Require a documentation audit as a transfer readiness gate: architecture decisions, runbooks, on-call procedures, and vendor relationships all need to exist in a form the client's new hires can read without a phone call to someone who just left.

BOT vs ODC vs staff augmentation: which engagement model fits?

The right model depends on whether the client wants to own the team eventually, and how much of the build risk it wants a vendor to absorb first.

Choosing the wrong row on this table is expensive. A company that actually wants a captive GCC but signs an ODC contract will find it can never fully own the team it's paying for. A company that wants ongoing flexibility but signs a BOT engagement model will pay for a transfer it never uses.

What should a BOT contract checklist cover?

A BOT contract needs to answer questions the parties would rather defer, written down before anyone has an incentive to be vague. At minimum:

• Transfer pricing formula, tied to specific assets (lease, licenses, equipment), not "fair market value"
• IP assignment terms fixed for the build and operate phases, not renegotiated at transfer
• Named roles required to transfer, with retention incentives that survive the handover date
• Documentation standards treated as a deliverable during operate, with an audit gate before transfer
• Transition support window: how many weeks of vendor support continue after legal transfer
• Data residency and compliance obligations that carry over to the client entity
• Objective transfer-readiness criteria, agreed at signing, not decided unilaterally by either party

Every item on this list is cheap to negotiate before build starts and expensive to negotiate during transfer, when one side has already built use the other side didn't have on day one.

Is build operate transfer software development right for every company?

No. BOT suits companies that want eventual ownership of an engineering team but lack the local entity, hiring pipeline or labor-market knowledge to build one directly. It doesn't suit companies that want flexibility to scale a team up or down without owning it.

If a company isn't sure yet whether it wants a permanent captive presence in a given market, an ODC or a fractional engagement is the lower-commitment choice; BOT locks both parties into a transfer that has real switching costs if the client changes its mind at month eighteen. Fractional senior engineering leadership, of the kind available through CTO-as-a-Service, is worth evaluating first if the actual gap is decision-making capacity rather than headcount.

A dual-shore model already running in Mohali

Viithiisys has engineered software from Mohali in the Chandigarh tricity since 2007, with a client-facing office in Markham, Ontario, opened as the company grew its US, UK and Canadian client base. That's 19 years of the same dual-shore shape now being formalized as a GCC strategy across Punjab: delivery in India, client relationship on the client's side of the clock.

Across 500+ shipped projects for clients including Paytm, Snapdeal, IKEA, Nestlé, Shiprocket and Vikram Solar, the pattern has been consistent engineering ownership rather than a rotating bench. On Conscious Chemist, a skin-analysis and AI assistant wired into the website and CRM lifted conversion by 15%, client-confirmed. On Fitelo, a voice-first coaching layer went into an existing app and coach workflow without disrupting either.

That kind of continuity is what a BOT transfer is trying to recreate artificially at month 24: a team that already knows the client's product, documented well enough that ownership can change hands without anything breaking. Companies evaluating enterprise software or custom software development partners in India can use the same criteria from this article's checklist to evaluate an ongoing partner, not just a BOT vendor.

Where to start before you sign a BOT contract

Start by pressure-testing the transfer clause in whatever term sheet is currently on the table, not the build timeline or the day rate. Ask for the pricing formula in writing, ask which named individuals are contractually required to transfer, and ask to see a sample of the documentation the vendor produces during operate, before signing anything.

If the answers are vague, that vagueness is the actual risk in the deal, not a detail to sort out later. A broken workflow assessment is a useful gut check even outside a formal BOT negotiation: it surfaces where a delivery process depends on undocumented tribal knowledge before that gap becomes someone else's problem at handover. For a direct conversation about scope, get in touch.