How Build-Operate-Transfer Works: A Founder's Plain-English Guide
Build-Operate-Transfer lets you launch a software product without hiring a single engineer — and still end up owning everything. Here's how the three phases actually work, what the contract must say, and the trade-offs nobody puts in the brochure.
You have the domain knowledge, the customers, maybe even the revenue — but no engineering team. The standard menu of options each carries a known failure mode: freelancers disappear after launch, agencies hand you a codebase you can't maintain, and hiring your own team means recruiting people whose work you can't evaluate, in a market where talent is scarce. A Gartner survey of IT executives found talent shortage cited as the single biggest barrier to adopting 64% of emerging technologies — far ahead of cost or security.
Build-Operate-Transfer (BOT) is the fourth option, and it works differently from all three. Here is exactly how — phase by phase, contract clause by contract clause.
What build-operate-transfer actually means
BOT started in infrastructure: a government wants a highway but lacks the capability to build and run one, so a private firm builds it, operates it for a fixed period to recover its investment, then transfers it to the state. The IT industry adapted the same logic for software teams and products.
In a software Build-Operate-Transfer engagement, a partner firm:
- Builds your product — scoping, architecture, development, launch.
- Operates it as a live business asset — hosting, support, fixes, and ongoing improvement, for an agreed period.
- Transfers the whole thing to you — code, infrastructure, accounts, documentation, and sometimes the team itself — once you're ready to own it.
The critical difference from project outsourcing is where the engagement ends. An outsourced project ends at delivery: the agency ships, invoices, and moves on, and the riskiest years of a product's life — the ones after launch — become entirely your problem. A BOT engagement ends at ownership: the partner is contractually on the hook for the product working in the real world, and is judged on the condition of what it hands over.
That alignment matters more than it sounds. Research by McKinsey and Oxford University across more than 5,400 projects found that large IT projects run 45% over budget on average while delivering 56% less value than predicted — and 17% go badly enough to threaten the existence of the company. Most of that damage shows up not in the build, but in the gap between "delivered" and "actually working for users." BOT is structured so the builder lives inside that gap with you.
The three phases, step by step
Phase 1: Build
The build phase typically runs three to nine months for a first product version, depending on scope. A serious partner will start with discovery — pressure-testing what the product must do, for whom, and what the smallest credible first version looks like — before writing code. Your job in this phase is not technical: it's decisions, domain knowledge, and access to real users.
Two things should be true from the first week:
- Intellectual property is assigned to you from the first line of code. Not at transfer. Not on final payment. If a partner wants to hold IP until the end, that's leverage they're building over you, and you should walk away.
- You hold or co-hold the keys. Cloud accounts, domain names, app store listings, and source code repositories should be created under your ownership (or with you as co-owner), with the partner operating them. If everything lives in the partner's accounts, the "transfer" phase becomes a renegotiation.
Phase 2: Operate — the phase everyone underestimates
This is the phase that distinguishes BOT from everything else, and the one founders most often misjudge. Software is not finished at launch; it's started. Real users do unexpected things, payment integrations fail at 2 a.m., the operating system or browser updates break something, and the feature you were sure mattered turns out to be ignored while users hammer on something you almost cut.
During the operate phase — commonly one to three years — the partner runs the product as if it were their own: monitoring, security patches, customer-facing bug fixes, infrastructure costs management, and a steady iteration rhythm based on real usage data. You operate the business: sales, pricing, partnerships, customer relationships. The division of labour is clean, and each side does the thing it's actually good at.
The operate phase is also when your eventual ownership gets built. A good partner uses this period to document how everything runs, and — if your plan includes an in-house team — to help you hire and train the people who will take over, with your future hires working alongside the partner's engineers before the handover rather than after it.
Phase 3: Transfer
Transfer is a process, not an event. What changes hands:
- Code and history — repositories with full commit history, not a zip file.
- Infrastructure — cloud accounts, databases, CI/CD pipelines, monitoring, with admin control moved to you.
- Accounts and contracts — domains, app store accounts, third-party services (payments, email, analytics) and their billing.
- Knowledge — architecture documentation, runbooks ("what to do when X breaks"), and a record of why key decisions were made.
- People, sometimes — in team-centric BOT deals, the engineers themselves move onto your payroll (called "rebadging"). In product-centric deals, it's more common that your own team takes over while the partner stays available for a defined support tail.
Transfer is triggered by whatever the contract says: a fixed date, a milestone (revenue, user count, your team passing a readiness review), or your decision within an agreed window. The strongest arrangements include a paid overlap period — 30 to 90 days where your team runs the product while the partner shadows — so problems surface while help is still in the room.
Why the model is having a moment
BOT is not a niche arrangement; it's how some of the world's largest companies now enter India. Deloitte's 2024 Global Outsourcing Survey found that 78% of surveyed organisations now use global in-house centres, and roughly half of adopters favour a build-operate-(transform)-transfer model — using third-party expertise to stand the operation up before taking full ownership.
India is the centre of gravity for this. The NASSCOM India GCC Landscape Report puts India's global capability centres at over 1,700 centres generating roughly $64.6 billion in annual revenue and employing more than 1.9 million people, and Forrester's analysis of NASSCOM's 2025 outlook projects the count growing past 2,100 by 2030.
Why should a founder care about Fortune 500 behaviour? Because the logic scales down. Enterprises choose BOT for exactly the reasons an SME should: it converts a large upfront capability-building risk into a staged, reversible commitment, with an expert carrying execution risk until the operation has proven itself. A founder in Indore or Idaho with a ₹40 lakh product budget faces the same structural problem as a bank opening a Bengaluru centre — they just face it with far less room for error.
BOT vs the alternatives
| Freelancers | Project agency | Hire in-house | Build-Operate-Transfer | |
|---|---|---|---|---|
| Upfront commitment | Low | Medium | High (salaries before product exists) | Medium |
| Who carries delivery risk | You | Shared until delivery | You | Partner, through operation |
| After launch | Usually gone | Paid support contract, best-effort | Your team (if it's good) | Partner operates by design |
| Technical hiring needed now | No | No | Yes — your hardest problem | No — deferred until transfer |
| What you own at the end | Code, condition unknown | Code + docs, no running operation | Everything, if it works | Running product, infrastructure, docs, trained team |
| Best for | Prototypes | Well-specified one-off builds | Funded startups with technical leadership | Founders/SMEs without a technical team who want eventual ownership |
No single column wins universally — a funded startup with a strong CTO should usually just hire. The comparison worth making is against your actual situation, which is why we lay out the full set of engagement models side by side rather than pretending BOT fits everyone.
What the contract must spell out
If you take one section from this article into a partner meeting, take this one. A BOT agreement is only as good as its specifics:
- IP assignment from day one, in writing, unconditional on payment disputes being resolved in the partner's favour.
- Named transfer triggers — a date, a milestone, or your option, but written down. "When you're ready" is not a clause; it's a future argument.
- The transfer fee, if any — some partners charge a handover fee, some build it into operate-phase pricing. Either is workable; unstated is not.
- What "operate" includes — response times for outages, support hours, how much iteration capacity (new features vs. maintenance) each month buys.
- Exit clauses in both directions — what happens if you want out early, and what happens if the partner fails to meet service levels. Including what you receive (everything built so far) in each case.
- Documentation obligations — runbooks and architecture docs as a deliverable, not a courtesy.
- Account ownership — an appendix listing every third-party account, who owns it today, and who owns it at transfer.
The honest trade-offs
BOT is not the cheapest line on a spreadsheet, and a partner who tells you otherwise is selling, not advising.
You pay for operation, not just construction. Over a two-to-three-year arc, a BOT engagement costs more in total than a one-off agency build — because it includes years of running, fixing, and improving that the one-off quote silently excludes. The fair comparison is BOT versus agency build plus the maintenance, rework, and rescue costs that follow, and against the McKinsey overrun figures above, staged operation usually compares well. But the headline number is bigger, and you should budget for that honestly.
Lock-in risk is real if the contract is vague. Everything in the previous section exists because some BOT deals are structured to make leaving expensive. The model itself is sound; a bad contract can corrupt it.
Partner quality is everything. A BOT partner is making a multi-year claim: that they can run software in production, not just write it. The cleanest evidence is whether they operate live products of their own — at Ganakys, that's the products we build and run ourselves, which is also where our operating playbooks come from. Whoever you talk to, ask to see something they keep alive, not just something they once shipped.
Transferring too early recreates the original problem. If you take ownership before you have people who can run the product, you've paid a premium to arrive back at square one. It's legitimate — and common — to extend the operate phase, or to transfer ownership while retaining the partner for support. Treat the transfer date as a readiness decision, not a deadline.
Is BOT right for you?
A strong fit if: you're a domain expert or SME owner with a validated problem and paying customers (or a clear path to them); you want to own your product and margins long-term rather than rent software forever; and you can fund a multi-year arc rather than only a build.
A poor fit if: you're pre-validation and just need a cheap prototype to test demand; you already have technical leadership who can hire and manage a team; or you need the absolute minimum spend this quarter regardless of what happens after launch.
For Indian founders specifically, there's a quiet advantage: the same engineering market that global enterprises are paying a premium to access through GCCs is your home market. A BOT arrangement lets you use it at local cost structures — and in INR terms, deferring the fixed cost of a senior in-house team (easily the largest line item in any software plan) until the product is generating revenue is often the difference between a fundable plan and an unfundable one.
If you want to see how this maps onto your specific product, start a BOT conversation with us — the first step is a scoping discussion, not a contract.