Build-Operate-Transfer for Founders: What Actually Transfers

The model you're being sold vs. the one enterprises actually buy

Build-Operate-Transfer didn't start in software. It's an infrastructure contract structure — toll roads, ports, power plants — where a private party builds an asset, runs it long enough to prove it works, then hands ownership to the state on a pre-agreed date at a pre-agreed price. The offshoring industry borrowed the shape, and it stuck.

At enterprise scale in India, it is genuinely mature. India now hosts 2,117 Global Capability Centres generating $98.4 billion in revenue and employing 2.36 million people, according to the Zinnov–NASSCOM India GCC Landscape Report 2026. Multinationals routinely use a partner to stand up an India centre — entity registration, banking, compliance, payroll, hiring, workspace — operate it for roughly 36 months, then take full ownership under a pre-agreed transition plan, as NASSCOM's own community analysis describes. Deloitte sells a variant it calls Build-Operate-Transform-Transfer. Oliver Wyman tracks the same evolution.

So the model is real. The problem is what happens when the word travels down-market.

When a development shop offers a first-time founder "BOT," it very often means: we'll build your app, we'll keep running it, and one day you can hire the team if you want to. That is not Build-Operate-Transfer. That is outsourcing with a friendly adjective attached.

Here is the test, and it's the most useful sentence in this post:

> BOT is defined by the transfer being dated, priced, and contractually enforceable at the moment you sign — not at the moment you leave.

If the handover terms are "we'll work that out later," there is no T in your BOT. You have a retainer with an exit-shaped hole in it. Every other consideration in this article is downstream of that one.

The three phases, and where each one actually breaks

Build

The partner assembles the team and ships the first working version of the product. This phase looks the most like normal agency work, and it's where founders concentrate almost all of their attention — scope, designs, timelines, price.

Where it breaks: the build phase quietly sets your lock-in. If the code lives in the vendor's GitHub organisation, deploys to the vendor's AWS account, and sits on the vendor's in-house "accelerator framework," you have bought a product you cannot physically leave with. None of that is visible in a demo. All of it is visible on transfer day, which is exactly too late.

Operate

The partner runs the thing in production — deployments, uptime, bugs, support, iteration on real user feedback. This is the phase founders underrate and the phase that actually carries the value.

Running software is a different discipline from writing it. On-call, incident response, cost control, security patching, the boring weekly rhythm of shipping — this is knowledge that only exists after contact with real users. Buying it for the eighteen months while you're finding product-market fit is the honest argument for BOT.

Where it breaks: the operate phase is comfortable. Someone else is holding the pager. Founders extend it, and extend it again, and the muscle that was supposed to be built inside their company never forms.

Transfer

Ownership moves. Code, infrastructure, IP, documentation, and — the part that matters most and gets specified least — the people.

Where it breaks: everywhere, if you didn't write it down at signing. The failure modes are well known to anyone who has done this: handover under-specified in the original contract, key engineers leaving at exactly the moment their knowledge is needed, documentation that describes what the system does but never why, and a receiving team that can read the code but cannot run it.

I'll be straight about the evidence here: the BOT-risk literature that shows up in a search is written almost entirely by firms selling BOT. That's marketing, not research, and I'm not going to dress it up as a statistic. Treat the list above as field experience, not a citation.

The enterprise playbook does not port to a startup

This is the part almost nobody says out loud, and it's why copying the GCC model wholesale is a mistake.

Enterprise BOT quietly assumes three things you probably don't have:

1. A receiving organisation. When Unilever takes over its India centre, there's an existing HR function, an IT function, a finance team, and a CTO who has received centres before. When a two-person founding team "receives" a product, the receiving organisation is a person who has never managed an engineer.
2. A validated mandate. The enterprise knows what the centre is for before building it. A founder is still finding out. CB Insights' post-mortem research puts poor product-market fit at 43% and bad timing at 29% among failure causes — and notes that "ran out of cash," the headline reason, is almost always the final cause of death rather than the root problem. Your build is a hypothesis, not a mandate.
3. Scale economics. 36 months and hundreds of seats amortise a lot of setup cost. You need four to eight good people and you need them to matter next quarter.

So the object being transferred is fundamentally different. An enterprise receives an entity — a legal shell, a lease, a payroll. A founder receives a codebase, a runbook, and two to four people who have agreed to stay. Any partner who quotes you the enterprise GCC script — entity setup, compliance, workspace — is selling you the wrong product at the wrong size. That's the specific mismatch our Build-Operate-Transfer engagement is shaped around, and it's why the transfer artefact is a working team and a system you can run, not a subsidiary.

How BOT compares to the realistic alternatives

No model dominates. Pick by what you're optimising for.

If you're weighing these seriously, the trade-offs across engagement models matter more than the day rate. The day rate is the least interesting number in the contract.

What makes a transfer real instead of theatrical

This is the checklist. If a BOT proposal doesn't survive it, it isn't one.

• A dated, priced transfer at signing. Not a formula, not "fair market value at the time," not a promise. A date and a number, agreed while both sides are still friendly.
• Your accounts from day one. Your cloud account, your repository organisation, your domain registrar, your app store listings. The partner gets access to your infrastructure — not the reverse. This one term eliminates most lock-in.
• IP assignment covering every contributor, including subcontractors and anyone who touched a line of code. Ask specifically about subcontractors.
• Named transfer team plus a retention structure. "We'll help you hire" is not a plan. Which humans, on what terms, with what incentive to still be there ninety days after handover?
• Documentation with an acceptance test, not a page count. The only test that means anything: a competent engineer who has never seen this system clones it, runs it locally, and ships a small change to production in their first week — unaided. If that fails, the documentation failed, however thick it is.
• Reverse shadowing before the date. For the final stretch, your people drive and the partner watches. Every BOT that goes wrong skipped this and called a demo a handover.
• No proprietary vendor frameworks. Boring, widely-known technology is a transfer feature. A clever internal framework only your partner understands is lock-in wearing an engineering costume.

The honest case against BOT

BOT costs more per month than straight outsourcing. You are buying an option to own, and options are never free. Three situations where you should not buy it:

You don't actually want a team. Plenty of good businesses never need in-house engineers. If you're happy with a vendor running your software for the next five years, buy managed development and skip the premium. Wanting to own a team is a real decision — make it deliberately, not by default.

You're too early. If you haven't validated the problem, a 24-month BOT commitment is a bet on a hypothesis. Buy eight to twelve weeks of validation first. The cheapest product is the one you don't build.

You can't fund the operate phase to its end. A transfer that happens because money ran out isn't a transfer. It's an eviction, and you'll receive a system nobody has time to explain to you.

One more piece of honesty, because this number gets weaponised constantly. You'll see it claimed that IT projects run 45% over budget and deliver 56% less value than predicted. That's real research — McKinsey with Oxford, across 5,400 projects — but it studied projects with budgets above $15 million, and it dates to 2012. It is not a finding about your ₹40 lakh MVP, and anyone quoting it at you to sell a de-risking service is hoping you won't check. The transferable insight isn't the percentage; it's the mechanism McKinsey identified — overrun scales with duration. Every extra year raised cost overruns by about 15%. Short cycles with a real thing in front of real users is the actual risk control. That's a design principle, not a statistic.

What to ask before you sign

Four questions, in order of how much they reveal:

1. "What is the transfer price, and what date is it on?" Hesitation here tells you everything.
2. "Whose AWS account is production in on day one?" If the answer isn't "yours," ask why not.
3. "Which named engineers transfer, and what makes them stay?" Retention costs money. Someone is paying it. Find out who.
4. "What happens if I want to transfer early?" A confident partner has an answer. A partner whose model depends on you never leaving does not.

On that third question, note the market you're transferring into. Zinnov projects GCC salary increments of around 11.5% for 2026, against roughly 9.1% across India Inc — see its salary, attrition and hiring trends analysis. Your transferred engineers are landing in one of the most competitive talent markets in the world, being actively recruited by centres with deeper pockets than yours. Retention isn't a soft concern to sort out later. It's a line item, and if it isn't in the contract, it isn't real.

Where to start

If you have a product idea, domain expertise, and no engineering team, the sequence that tends to work is unglamorous: validate narrowly, build the smallest real thing, put it in front of users, and only then decide whether you want to own a team at all. BOT earns its premium in the gap between "this works" and "I'm ready to run it" — not before, and not indefinitely.

We run this model ourselves, on our own products as well as clients' — Codilla.ai and AIcreators.cloud are ours, which is a reasonable thing to hold us to. It also means transfer day isn't a theoretical event to us.

If you want to pressure-test whether BOT actually fits your situation — including the honest answer that it might not — start a BOT conversation and bring the checklist above. Use it on us.