Build-Operate-Transfer erklärt: der dritte Weg zwischen Inhouse-Einstellung und gemieteter Agentur

Die meisten Gründer, mit denen wir sprechen, haben dieselben zwei Gespräche bereits hinter sich. Im ersten nennt ein Recruiter vier bis sechs Monate, um einen Senior Engineer in Deutschland einzustellen – plus ein Honorar von grob einem Viertel des ersten Jahresgehalts. Im zweiten nennt eine Agentur einen Tagessatz, der sich Jahr für Jahr auf mehr summiert als die Zahl des Recruiters – und alles, was das Team gelernt hat, geht am Ende jedes Vertrags mit durch die Tür.

Build-Operate-Transfer existiert für Unternehmen, die beide Gespräche für inakzeptabel halten. Wir betreiben BOT bei SolutionPlus als eines unserer zentralen Delivery-Modelle – dies ist also keine neutrale Übersicht. Es ist die Sicht von der Seite, die das Modell besetzen und steuern muss, inklusive der Teile, die schiefgehen.

Was BOT ist (und die 2 Dinge, die es nicht ist)

BOT ist ein Delivery-Modell mit drei kommerziellen Phasen. Ein Partner baut ein dediziertes Engineering-Team für Sie auf: Recruiting, Anstellung, Tooling – das komplette Paket. Anschließend betreibt der Partner dieses Team an Ihrem Produkt, nach Ihren Prioritäten, über Monate oder Jahre. Zu einem Zeitpunkt, den Sie bestimmen, geht die gesamte Leistungsfähigkeit in Ihre Organisation über. Die Menschen, die Repositories, die Runbooks, die Gewohnheiten. Nach dem Transfer ist der Partner draußen – oder bleibt freiwillig über ein kleines Support-Retainer an Bord, statt aus Abhängigkeit.

Zwei Dinge ist es nicht. Erstens ist es keine Staff Augmentation mit hübscherem Etikett. Augmented Engineers werden nie zu Ihren eigenen. Es gibt kein Transfer-Ereignis, keinen Exit – und das kommerzielle Interesse des Anbieters läuft darauf hinaus, Sie als Mieter zu halten. Zweitens ist es kein Fixed-Price-Projekt mit Wartungsklausel. Ein Projekt endet, und das Team löst sich im nächsten Einsatz des Anbieters auf. BOT endet mit einem intakten Team, das für Sie arbeitet. Wenn ein Vertrag BOT sagt, aber keinen bepreisten, terminierten Transfer enthält, dann sehen Sie eine Staff Augmentation im Anzug.

Unsere Variante verbindet internationale Projektleitung mit einem Senior-Engineering-Team in Pakistan, geliefert auf Englisch oder Deutsch. Diese Kombination ist das Betriebsmodell hinter unseren Dedicated Delivery Teams – und BOT ist das, was passiert, wenn man diesem Modell einen Endzustand gibt.

Die 24-Monats-Rechnung: Inhouse vs. Agentur vs. BOT

Dasselbe Problem, dreimal gerechnet. Sie brauchen vier Senior Engineers und einen Teilzeit-Tech-Lead, zeitnah, für mindestens zwei Jahre. Was folgt, sind Planungskorridore aus unseren eigenen Angeboten und den Hiring-Daten, die wir im deutschen Markt sehen. Es sind keine Angebote, und Ihre Zahlen werden anders aussehen.

Inhouse. Ein Senior Engineer in Deutschland kostet mit allen Nebenkosten – Arbeitgeberanteile, Ausstattung, Management-Overhead – 95.000–130.000 € pro Jahr. Vier davon: 760.000–1.040.000 € über 24 Monate. Dazu Recruiting-Gebühren von 20–30 % des ersten Jahresgehalts pro Einstellung, weitere 80.000–150.000 €, wenn eine Personalvermittlung alle vier platziert. Und dann die Zeile, die niemand in die Tabelle schreibt: vier bis sechs Monate pro Einstellung, in denen der Platz leer bleibt. Der Digitalverband Bitkom bezifferte die unbesetzten IT-Stellen in Deutschland auf 149.000 in seiner Erhebung 2023 – ein Gefühl dafür, wie umkämpft dieser Arbeitsmarkt ist. Realistische Zeit bis zum vollständigen Team: 9–12 Monate. Am Ende gehört Ihnen alles – aber das Ende beginnt ein Jahr zu spät.

Agentur. Deutsche Agenturen liegen bei Senior-Leistungen mit gemischten Stundensätzen bei 100–160 €. Vier Vollzeit-Engineers zu 120 € ergeben rund 77.000 € pro Monat, etwa 1,85 Millionen € über 24 Monate. Sie starten innerhalb von Wochen – das ist der echte Vorteil dieses Wegs. Aber die Rechnung hört nie auf, und in Monat 24 besitzen Sie den Code, aber nichts von der Fähigkeit, die ihn geschrieben hat.

BOT. Unsere Bandbreite liegt bei 25–49 $ pro Stunde, je nach Seniorität und Stack. Dasselbe Team mit einem gemischten Satz von 38–45 $ kommt auf etwa 24.000–29.000 $ pro Monat. Achtzehn Monate Build-and-Operate plus Transferphase landen all-in bei rund 450.000–600.000 € – und am Ende gehört das Team Ihnen.

Hier der Trade-off, den wir im ersten Gespräch offenlegen: BOT ist in Monat eins nie die günstigste Option, und es schlägt die Agentur bei den Kosten nur, wenn Sie lange genug bleiben, damit sich der Transfer amortisiert. Unter zwölf Monaten: Mieten Sie einfach.

Die Wirtschaftlichkeit folgt aus dem Modell, nicht umgekehrt. Sie zahlen eine Anbietermarge statt zwei, zu pakistanischen Engineering-Sätzen unter deutscher Projektsteuerung, und die Delivery-Gebühr des Anbieters endet mit dem Transfer. Was weiterläuft, sind die Kosten, die Sie besitzen wollten: die Gehälter der übernommenen Engineers auf Ihrer Payroll, plus ein Support-Retainer, falls Sie eines behalten wollen. Wenn Sie über die MVP-Phase hinaus skalieren und bereits wissen, dass das Produkt jahrelang ein Team brauchen wird, ist gegen diese Kurve schwer zu argumentieren.

Wie die Transferphase funktioniert, Woche für Woche

Alles vor dem Transfer ist ein Dedicated-Team-Engagement mit einem Enddatum im Vertrag. Das Muster unten stammt von einem B2B-Logistiksoftware-Kunden, dessen Fünferteam in Monat 19 überging. Namen und Details sind geändert; die Abfolge ist echt.

Die Monate 1–2 waren Recruiting auf Stack und Domäne des Kunden; der Kunde interviewte jeden Finalisten und hatte ein Vetorecht. In den Monaten 3–6 lieferte das Team unter unserem Tech-Lead, während der Product Owner des Kunden an Planning und Reviews teilnahm. Die Monate 6–18 waren die eigentliche Operate-Phase: Unser Tech-Lead gab Architekturentscheidungen schrittweise an den Product Owner des Kunden ab, und die neue Engineering-Einstellung des Kunden (rund um Monat 14 eingestellt) arbeitete zwei Tage pro Woche eingebettet im Team. In Monat 17 vereinbarten wir das Transferdatum. Der Transfer selbst dauerte acht Wochen:

• Wochen 1–2: Repositories und Zugänge. Jedes Repo, jede CI-Pipeline, jedes Cloud-Konto und jeder Drittanbieter-Key wandert in Organisationen im Besitz des Kunden – oder bekommt einen schriftlichen Migrationsplan mit namentlich genanntem Owner.
• Wochen 3–4: Runbooks. Jeder wiederkehrende Vorgang (Deploys, Rollbacks, Incident Response, Datenkorrekturen) wird aufgeschrieben und dann einmal vom eintretenden Engineer des Kunden ausgeführt, während unser Engineer zusieht und nichts sagt.
• Wochen 5–6: Zeremonien. Der Product Owner des Kunden leitet Standup, Planning, Reviews und Retros. Unser Tech-Lead nimmt als Beobachter teil. Das ist die Woche, die ans Licht bringt, was die Dokumentation übersehen hat.
• Woche 7: Übertragung der Anstellungen. Arbeitsverträge, Kündigungsfristen, Gehaltsbänder, Starttermine. Es sind die Menschen, die wechseln, nicht nur die Artefakte – und die Menschen müssen es wollen.
• Woche 8: Shadow-Support. Wir fallen für 60–90 Tage auf ein kleines Retainer zurück: erreichbar, aber nicht mehr im kritischen Pfad.

Die Reihenfolge ist entscheidend. Wissen lebt mehr in Gewohnheiten als in Dokumenten (die Team-Topologies-Leute nennen das Team Cognition), deshalb wandern die Zeremonien nach den Runbooks, nicht davor. Ein Dokumentations-Dump in Woche 1 fühlt sich effizient an und scheitert in Monat 3 – beim ersten Incident um 2 Uhr nachts, wenn niemand weiß, wen man anruft.

Der Punkt, der tatsächlich bricht, ist Woche 7. In einem früheren Engagement verloren wir beim Transfer einen starken Engineer, weil er den Arbeitgeber nicht wechseln wollte – und wir hatten keine Reserve hinter ihm. Wir planen inzwischen damit, dass ungefähr jeder fünfte Engineer den Transfer ablehnt – unsere Heuristik aus den Übergaben, die wir durchgeführt haben – und rekrutieren entsprechend. Budgetieren Sie dafür. Ein Transferplan, der annimmt, dass 100 % der Menschen ja sagen, ist ein Plan, der nur in Slidedecks funktioniert.

Wann BOT die falsche Wahl ist

Wir reden etwa ein Drittel der BOT-Anfragen, die uns erreichen, wieder aus dem Modell heraus. Drei Fälle kehren immer wieder.

Sie wollen Engineering nie besitzen. Wenn Software für Sie immer etwas sein wird, das man kauft, statt etwas, das man ist, kauft die BOT-Prämie einen Ausstieg, den Sie nicht brauchen. Schlichte Staff Augmentation ist einfacher – und ehrlich in dem, was sie ist.

Sie brauchen sechs Leute für zehn Wochen. Die Transfer-Maschinerie (Runbooks, Zeremonien, Hiring-Übergabe, Governance) amortisiert sich nur über ein Jahr oder mehr. Für eine Spitzenlast: Mieten Sie ein Team und lassen Sie es ohne Zeremonie wieder gehen.

Sie können noch nicht sagen, was das Team bauen soll. Wenn der Pivot noch vor Ihnen liegt, ist es verfrüht, eine Teamform in einem Transferplan festzuschreiben. Beginnen Sie mit einem Sprint mit festem Umfang (unser MVP-Paket läuft etwa vier Wochen), lernen Sie, was das Produkt ist – und sprechen Sie dann darüber, ein Team zu besitzen.

Ein Anbieter, der Ihnen in einer dieser Situationen BOT verkauft, verkauft Ihnen in Wahrheit sein Umsatzziel.

Was in den BOT-Vertrag gehört

Die Klauseln, die entscheiden, ob ein BOT-Engagement echt ist:

• Ein Transfer-Auslöser: ein Datum oder objektive Bedingungen wie Teamgröße und Betriebszugehörigkeit, die die Acht-Wochen-Uhr starten.
• Der Preis des Transfers selbst. Eine Ablösesumme oder nichts – aber schriftlich. Mehrdeutigkeit an dieser Stelle ist der Punkt, an dem Transfers sterben.
• IP-Abtretung ab Tag eins, nicht ab dem Transferdatum.
• Eine Ersatzgarantie bei Fluktuation während der Operate-Phase, auf Kosten des Anbieters.
• Ausstiegsrampen für beide Seiten, mit Kündigungsfristen und Übergabepflichten, die zu jedem Zeitpunkt gelten – nicht nur zum geplanten Ende.
• Eine Definition von „dokumentiert". Unsere ist der Test aus Woche 3–4 oben: Ihr Engineer führt das Runbook aus, während unserer zusieht. Wenn der Vertrag den Test nicht beschreiben kann, ist die Dokumentationsklausel Dekoration.

Wir haben BOT-Verträge anderer Anbieter gesehen, die die Hälfte dieser Liste auslassen – und das Muster danach ist immer dasselbe: Die Operate-Phase zieht sich, der Transfer rutscht, und der Kunde mietet am Ende das Team, von dem ihm versprochen wurde, er würde es besitzen. Alles andere im Vertrag ist verhandelbar. Diese sechs Punkte sind es nicht.

Wenn Sie prüfen wollen, ob BOT zu Ihrer Situation passt, sprechen Sie mit uns. Wenn Sie sehen wollen, wie unsere Engagements aussehen, wenn sie live sind, zeigen die Fallstudien das betriebliche Ende des Modells. Das Modell selbst ist einfach. Die Disziplin steckt in der Übergabe.