Where Build-Operate-Transfer Deals Go Wrong

6

Ways BOT engagements typically come apart

18-36 mo

How long you are committed before transfer

2

Tax exposures to structure for upfront

0

Leverage you have once the build has started

Build-Operate-Transfer is the only outsourcing model where you sign a multi-year commitment before you find out whether the vendor can deliver the part that matters. The build works, usually. The operate phase works, mostly. Then you reach the transfer, and that is where BOT contract risks stop being theoretical.

That asymmetry is the whole problem, and it is why this decision belongs at CEO and CTO level rather than in procurement. What follows is where these engagements actually come apart, and what needs to be in the contract before the build starts, because none of it can be fixed in month twenty. If you need the mechanics of the three phases first, they are in our walkthrough of how the build-operate-transfer model works.

Why the risk sits with you, not the vendor

In a staffing engagement, a bad vendor costs you a quarter. You replace them and move on. In BOT, the vendor holds the legal entity, the employment contracts and the operating knowledge for the duration, and your exit only exists if someone wrote it down properly at the start.

Nothing about that is unusual or predatory. It is structurally how the model works, and it is the price of having someone else carry the compliance and hiring load in a country where you have no presence. But it means the contract is not paperwork. The contract is the product.

Six ways these deals come apart

1. 01

   The transfer has no trigger

   The contract says the entity transfers when the operation reaches maturity, and defines maturity nowhere. Without a specific trigger, defined acceptance criteria and an evidence standard for what counts as delivery, the handover date becomes a negotiation you enter with no leverage. Fix: name the metrics, name the threshold, and require the vendor to demonstrate it rather than assert it.
2. 02

   IP assigns at transfer, not at creation

   This one is easy to read past. If the contract promises to assign ownership at handover rather than assigning it automatically the moment work is created, you do not own two years of code, architecture or documentation until the transfer completes. Anything that delays the transfer delays your ownership of everything built so far. Fix: present-tense assignment language, covering code, docs and architecture, with flow-down to each individual engineer.
3. 03

   You cannot hire your own team

   Standard non-solicitation language, left unamended, can stop you employing the engineers the entire engagement was built around. Clients discover this at the point of transfer, which is the worst possible time. Fix: explicit no-poach exceptions naming the transferred team.
4. 04

   The transfer fee is uncapped

   Legal fees, migration support and knowledge transfer all get priced at the moment you are most exposed and least able to walk away. Fix: cap the transfer fee and require rate transparency in the contract, not in a later statement of work.
5. 05

   Employment succession is assumed rather than planned

   Polish labour law generally requires employment relationships to transfer under legal succession principles when a business or part of a business changes hands, with a notice period to affected employees beforehand. The vendor typically remains liable for obligations arising before the transfer date and you assume everything after. Get the timeline and liability split confirmed by qualified Polish counsel, because the specifics change and a wrong assumption here surfaces as a staffing crisis, not a legal footnote.
6. 06

   The vendor has never completed one

   Plenty of firms will sell the three-phase story. Far fewer have transferred an entity, migrated contracts under local succession law and walked away cleanly. If a vendor cannot produce evidence of a completed transfer or a sample transfer checklist, you would be their first, and you are funding their learning curve. Fix: ask for the evidence before the proposal stage, not after.

The two tax exposures worth structuring for upfront

Neither of these is a contract problem you can patch later, which is why they belong in the first conversation with your tax advisors rather than the last.

Permanent establishment. A centre running high-value economic activity without proper structuring can be treated by tax authorities in either jurisdiction differently than you intended. The consequences land on the parent company, not the vendor.

Transfer pricing. If regulators conclude that operate-phase services were priced in a way that does not reflect market rates, that becomes a question about the whole engagement. Worth reviewing while pricing is still being negotiated rather than after two years of invoices.

There is also a data dimension that arrives with the entity. Once you own an EU legal entity, you are the controller for data flowing through it, so GDPR becomes your obligation rather than your vendor's. Depending on your setup, mechanisms like Standard Contractual Clauses may be needed for cross-border transfers unless your company participates in a recognised framework. The one genuine advantage of an EU-based centre is that labour transfer rules and data protection frameworks here are well established and broadly match what US companies already run for EU-facing operations. Confirm the specifics with counsel rather than treating this as a compliance picture.

Evidence to demand before you sign

Ask for artefacts, not answers. A vendor who has completed transfers has these lying around. A vendor who has not will offer a conversation instead.

Swipe the table sideways to see all columns.

That last row is where timelines quietly stretch. A vendor with a pre-vetted pipeline is placing people in week two. A vendor opening a search after signature is placing people in month three, and the difference comes out of your runway rather than theirs. ITDS Nearshore sources from TalentHub for that reason.

What the board will actually ask

If you are taking a BOT proposal to a board or an exec team, expect three questions. Have the answers in the contract rather than in a deck.

• What exactly do we own, and when? Point to the IP assignment clause and the transfer trigger. If either is vague, the answer is "we do not know", and that is not an answer a board accepts on a multi-year commitment.
• What does it cost us to stop? Termination for breach, step-in rights, asset return schedule, transfer fee cap. If exit is undefined, the real cost of this engagement is unbounded.
• Who has done this before? Completed cycles and documented transfers, not client logos. This is the question most likely to change the decision, and the one most often skipped.

Governance answers the follow-ups. A joint steering committee from the start of the operate phase, a regular reporting cadence, and agreed dashboards covering sprint velocity, defect density, compliance adherence and team retention. Those numbers are also what evidences the transfer trigger when the time comes, which is a second reason to agree them early.

Frequently Asked Questions

Do the diligence while you still have leverage

None of this makes BOT a bad model. Done properly it is one of the few structures that gives you both speed and eventual ownership, and for companies building a European engineering hub without a local presence there is not much that competes with it.

But the model puts the risk on the client and the leverage with the vendor, and it does that from the moment the build starts. Every item above is cheap to fix in the contract and expensive to fix in month twenty. Ask the awkward questions now. Learn more about our turn-key BOT solution, or read why Poland is a smart choice for nearshoring IT services in Europe.