Most founders we talk to have already sat through the same two conversations. In the first, a recruiter quotes four to six months to hire one senior engineer in Germany, plus a fee of roughly a quarter of the first year's salary. In the second, an agency quotes a day rate that adds up to more than the recruiter's number, every year, with everything the team learns walking out the door at the end of each contract.
Build-operate-transfer exists for the company that finds both of those conversations unacceptable. We run BOT as one of our core delivery models at SolutionPlus, so this is not a neutral overview. It is how the model behaves from the side that has to staff and govern it, including the parts that go wrong.
What BOT is (and the 2 things it is not)
BOT is a delivery model with three commercial stages. A partner builds a dedicated engineering team for you: recruiting, employment, tooling, the lot. The partner then operates that team on your product, under your priorities, for months or years. At a point you choose, the whole capability transfers into your organization. The people, the repositories, the runbooks, the habits. After the transfer, the partner is out, or kept on a small support retainer by choice rather than dependency.
Two things it is not. First, it is not staff augmentation with a nicer label. Augmented engineers never become yours. There is no transfer event, no exit, and the vendor's commercial incentive runs toward keeping you renting. Second, it is not a fixed-price project with a maintenance clause. A project ends and the team dissolves into the vendor's next assignment. BOT ends with the team intact and working for you. If a contract says BOT but contains no priced, dated transfer, you are looking at augmentation wearing a suit.
Our version pairs German-led project leadership with a senior engineering team in Pakistan, delivered in English or German. That combination is the operating model behind our dedicated delivery teams, and BOT is what happens when you give that model an end state.
The 24-month math: in-house vs agency vs BOT
Same problem, three ways. You need four senior engineers and a part-time technical lead, starting soon, for at least two years. What follows are planning ranges from our own proposals and the hiring data we see in the German market. They are not quotes, and your numbers will differ.
In-house. A fully loaded senior engineer in Germany costs €95,000–130,000 per year once employer contributions, equipment, and management overhead are in. Four of them: €760,000–1,040,000 over 24 months. Add recruiting fees of 20–30% of first-year salary per hire, another €80,000–150,000 if an agency places all four. Then add the line nobody puts in the spreadsheet: four to six months per hire where the seat sits empty. The German digital association Bitkom put unfilled IT positions in Germany at 149,000 in its 2023 survey, which gives a sense of how competitive that hiring market is. Realistic time to a full team: 9–12 months. You own everything at the end, but the end starts a year late.
Agency. German agency blended rates for senior work run €100–160 per hour. Four full-time engineers at €120 come to roughly €77,000 per month, around €1.85 million over 24 months. You start within weeks, which is the genuine advantage of this path. The bill never stops, though, and at month 24 you own the code but none of the capability that wrote it.
BOT. Our rate band is $25–49 per hour depending on seniority and stack. The same team at a blended $38–45 runs about $24,000–29,000 per month. Eighteen months of build-and-operate plus a transfer period lands around €450,000–600,000 all-in, and at the end the team is yours.
Here is the trade-off we state on the first call: BOT is never the cheapest option in month one, and it only beats the agency on cost if you stay long enough for the transfer to amortize. Below twelve months, just rent.
The economics follow from the model rather than the other way around. You pay one vendor margin instead of two, at Pakistani engineering rates under German project governance, and the vendor delivery fee ends at transfer. What continues are the costs you wanted to own: the transferred engineers' salaries on your payroll, plus any support retainer you choose to keep. If you are scaling past the MVP stage and already know the product will need a team for years, that curve is hard to argue with.
How the transfer phase works, week by week
Everything before the transfer is a dedicated team engagement with an end date in the contract. The pattern below comes from a B2B logistics software client whose five-person team transferred in month 19. Names and details are changed; the sequence is real.
Months 1–2 were recruiting against the client's stack and domain, with the client interviewing every finalist and holding veto power. Months 3–6, the team shipped under our technical lead while the client's product owner joined planning and reviews. Months 6–18 were the operate phase proper: our lead gradually handed architectural decisions to the client's product owner, and the client's incoming engineering hire (made around month 14) embedded with the team two days a week. In month 17 we agreed the transfer date. The transfer itself took eight weeks:
- Weeks 1–2: repositories and access. Every repo, CI pipeline, cloud account, and third-party key moves into client-owned organizations, or gets a written migration plan with a named owner.
- Weeks 3–4: runbooks. Every recurring operation (deploys, rollbacks, incident response, data fixes) is written down, then executed once by the client's incoming engineer while our engineer watches and says nothing.
- Weeks 5–6: ceremonies. The client's product owner runs standup, planning, reviews, and retros. Our lead attends as an observer. This is the week that surfaces what the documentation missed.
- Week 7: hiring handoff. Employment contracts, notice periods, salary bands, start dates. The people transfer, not just the artifacts, and the people have to want it.
- Week 8: shadow support. We drop to a small retainer for 60–90 days, reachable but no longer in the critical path.
The order matters. Knowledge lives in habits more than in documents (the Team Topologies people call this team cognition), so ceremonies transfer after runbooks, not before. A documentation dump in week 1 feels efficient and fails in month 3, the first time an incident hits at 2 a.m. and nobody knows who to call.
The part that actually breaks is week 7. In an earlier engagement we lost a strong engineer at transfer because he did not want to change employers, and we had no bench behind him. We now plan for roughly one in five engineers declining the transfer, our heuristic from the handovers we have run, and recruit accordingly. Budget for that. A transfer plan that assumes 100% of the people say yes is a plan that works in slide decks.
When BOT is the wrong choice
We talk about a third of the BOT inquiries we get out of the model. Three cases recur.
You never want to own engineering. If software will always be something you buy rather than something you are, BOT's premium purchases an exit you have no use for. Plain staff augmentation is simpler and honest about what it is.
You need six people for ten weeks. The transfer machinery (runbooks, ceremonies, hiring handoff, governance) only amortizes over a year or more. For a spike, rent a team and let it go without ceremony.
You cannot yet say what the team should build. If the pivot is still ahead of you, locking a team shape into a transfer plan is premature. Start with a fixed-scope sprint (our MVP package runs about four weeks), learn what the product is, then talk about owning a team.
A vendor who sells you BOT in any of these situations is selling you their revenue target.
What to put in the BOT contract
The clauses that decide whether a BOT engagement is real:
- A transfer trigger: a date, or objective conditions like team size and tenure, that start the eight-week clock.
- The price of the transfer itself. A buyout fee or nothing, but written down. Ambiguity here is where transfers die.
- IP assignment from day one, not from the transfer date.
- An attrition replacement guarantee during the operate phase, at the vendor's cost.
- Exit ramps for both sides, with notice periods and handover obligations that apply at any point, not just at the planned end.
- A definition of "documented." Ours is the week 3–4 test above: your engineer executes the runbook while ours watches. If the contract cannot describe the test, the documentation clause is decoration.
We have seen BOT contracts from other vendors that skip half of this list, and the pattern afterward is always the same: the operate phase runs long, the transfer slips, and the client ends up renting the team they were promised they would own. Everything else in the contract is negotiable. These six are not.
If you want to pressure-test whether BOT fits your situation, talk to us. If you want to see what our engagements look like once they ship, the case studies show the operating end of the model. The model itself is simple. The discipline is in the handover.
Frequently asked questions
Who owns the IP during the operate phase of a BOT engagement?
You should, from day one. In our contracts every line of code, design, document, and config is assigned to the client as it is created, not at the transfer date. If a BOT contract assigns IP only at transfer, the vendor effectively holds your product for the entire operate phase.
How long does a BOT engagement take from kickoff to transfer?
In our experience, 18 to 24 months is the healthy range: two to three months to build the team, a year or more of operating, and about eight weeks for the transfer itself. Our planning rule, from the transfers we have supported since 2023, is to treat anything before month twelve as fragile: the knowledge has not had time to settle into habits.
What happens if we want to exit before the transfer?
That depends entirely on the contract, which is why exit ramps belong in it. Ours define notice periods and handover obligations for both sides at any point in the operate phase. You keep the code and documentation either way; what you give up by exiting early is the team.
Do we have to take over the whole team at transfer?
No. Most clients take the core team and leave some roles with us on a reduced retainer, typically QA or DevOps coverage they are not ready to hire for. Plan for attrition too: our planning heuristic from the transfers we have run since 2023 is that roughly one in five engineers may decline to change employers at transfer.