Alle Abbildungen in diesem Beitrag sind KI-generierte Symbolbilder. Sie zeigen keine realen Kunden, Projekte oder Mitarbeitenden.
Hinweis zur Einordnung: Dieser Beitrag erscheint im Unternehmensblog von H-Studio Berlin. Er ist eine praktische Entscheidungshilfe, keine objektive Marktstudie, Rechts- oder Personalberatung. Die passende Vertrags- und Teamstruktur hängt vom konkreten Unternehmen ab.
Kurze Antwort
Ein In-house-Team ist meist die stärkere Dauerlösung, wenn Software zum Kerngeschäft gehört, genügend kontinuierliche Arbeit vorhanden ist und technische Führung bereits intern funktioniert. Eine Engineering-Partnerschaft passt eher zu klaren Aufbau-, Modernisierungs- oder Skalierungsphasen, in denen Senior-Kompetenz schneller gebraucht wird, als sie verantwortbar eingestellt werden kann. Viele Unternehmen fahren am stabilsten hybrid: Produktverantwortung intern, zusätzliche Delivery- und Architekturkapazität extern, mit einem vereinbarten Übergabepfad.
Die Entscheidung sollte weder auf „Mitarbeiter sind immer günstiger“ noch auf „ein Partner ist immer schneller“ beruhen. Entscheidend sind der erwartete Arbeitsvorrat, vorhandene Führung, benötigte Kompetenz, Risikoverteilung und die Frage, wer das System in zwölf bis 24 Monaten betreiben soll.
Die Entscheidung in 30 Sekunden
| Situation | In-house-Team | Engineering-Partnerschaft | Hybridmodell |
|---|---|---|---|
| Software ist dauerhaftes Kerngeschäft | Sehr guter Fit | Ergänzung für Spezialthemen | Häufig guter Übergang |
| Der Bedarf ist zeitlich begrenzt oder phasenweise | Risiko von Leerlauf | Guter Fit bei klarem Scope | Gut bei wechselnder Last |
| Es fehlt technische Führung | Einzelne Neueinstellungen lösen das Problem nicht automatisch | Nur passend, wenn Entscheidungsverantwortung Teil des Mandats ist | Interner Product Owner plus externer Tech Lead kann funktionieren |
| Ein Build muss kurzfristig starten | Recruiting kann den Start verzögern | Start mit verfügbarem Team möglich | Partner startet, internes Team übernimmt schrittweise |
| Produktwissen ist hochgradig unternehmensspezifisch | Starker Vorteil | Wissenstransfer muss ausdrücklich organisiert werden | Produktwissen intern, Engineering gemeinsam |
| Betrieb und Weiterentwicklung laufen über Jahre | Sinnvoll bei stabiler Auslastung | Retainer nur mit klarer Betriebsverantwortung | Kernteam intern, Peaks und Reviews extern |
| Spätere Unabhängigkeit ist wichtig | Direkt gegeben, wenn Wissen nicht bei Einzelnen hängt | Repository, Accounts, Dokumentation und Exit müssen vereinbart sein | Übergabe ist Bestandteil der Roadmap |
Das Hybridmodell ist keine unverbindliche Mitte. Es ist nur dann ein eigenes Betriebsmodell, wenn Entscheidungsrechte, Zuständigkeiten und Übergabe konkret definiert sind.
Zuerst klären: Kaufen Sie Kapazität, ein Ergebnis oder Entscheidungskompetenz?
„Wir brauchen Entwickler“ ist noch kein ausreichender Bedarf. Hinter dem Satz können drei unterschiedliche Engpässe liegen:
- Kapazitätsengpass: Ein vorhandenes Team hat mehr priorisierte Arbeit als verfügbare Zeit.
- Kompetenzengpass: Für Architektur, Migration, Security, Daten oder Betrieb fehlt Erfahrung.
- Führungsengpass: Es fehlt jemand, der Scope, Trade-offs, technische Qualität und Risiken verbindlich steuert.
Eine zusätzliche In-house-Stelle kann einen dauerhaften Kapazitätsengpass lösen. Sie löst nicht automatisch fehlende Architekturverantwortung. Ein externer Partner kann eine begrenzte Build-Phase übernehmen. Er darf aber nicht stillschweigend zum Product Owner werden, wenn die geschäftlichen Prioritäten intern niemand entscheidet.
Definieren Sie deshalb vor der Modellauswahl einen Satz wie:
„Wir brauchen für die nächsten zwölf Monate ein Team, das den Kunden-Onboarding-Workflow von der bestehenden CRM-Landschaft bis zum produktiven Betrieb liefert, während Produktprioritäten und fachliche Abnahme intern bleiben.“
Dieser Satz ist beschaffbar. „Zwei Full-Stack-Entwickler“ ist zunächst nur eine Rollenbezeichnung.
Der deutsche Einstellungsmarkt 2026: weder einfacher Mythos noch pauschaler Mangel
Auch der Arbeitsmarkt spricht gegen pauschale Aussagen. Die Fachkräfteengpassanalyse 2025 der Bundesagentur für Arbeit weist Softwareentwicklung im Unterschied zum Vorjahr nicht mehr als allgemeinen Engpassberuf aus. Gleichzeitig berichtet die BA für 2025 von rund 13.000 gemeldeten IKT-Stellen im Jahresdurchschnitt und einem gegenüber 2024 deutlich gesunkenen Stellenbestand.
Das bedeutet nicht, dass jede passende Besetzung leicht ist. Das Statistische Bundesamt zeigt für das Erhebungsjahr 2023, dass 72 % der Unternehmen mit ausgeschriebenen IT-Stellen Schwierigkeiten bei der Besetzung meldeten. Beide Befunde können gleichzeitig stimmen: Der Gesamtmarkt hat sich abgekühlt, während bestimmte Profile, Branchen, Regionen oder Senioritätsstufen weiterhin schwer zu besetzen sind.
Für die Entscheidung folgt daraus: Planen Sie nicht mit einem allgemeinen „Fachkräftemangel“, sondern mit Ihrem konkreten Rollenprofil. Prüfen Sie Gehaltsrahmen, Standortmodell, erforderliche Domänenkenntnis, Interviewkapazität und realistische Kandidatenpipeline. Ein externer Partner ist kein Ersatz für diese Analyse, sondern eine andere Art, einen zeitlich und fachlich definierten Bedarf abzudecken.
Wann ein In-house-Team die stärkere Wahl ist
Eine interne Einstellung ist besonders sinnvoll, wenn mehrere dieser Bedingungen erfüllt sind:
- Die Arbeit bleibt bestehen. Es gibt nicht nur einen Launch, sondern einen belastbaren Produkt- und Betriebsbedarf über mehrere Jahre.
- Software differenziert das Geschäft. Produktentscheidungen, Daten oder Betriebswissen gehören dauerhaft ins Unternehmen.
- Technische Führung ist vorhanden. Jemand kann Rollen schneiden, Kandidaten beurteilen, Architektur reviewen und Entwicklung priorisieren.
- Die Auslastung ist planbar. Das Unternehmen kann die Rolle auch nach der aktuellen Build-Phase sinnvoll einsetzen.
- Lernen im Unternehmen ist strategisch. Wissen soll nicht nur dokumentiert, sondern täglich im Team weiterentwickelt werden.
- Betriebsverantwortung soll intern liegen. Monitoring, Incidents, Security-Updates und Roadmap werden langfristig vom eigenen Team getragen.
In-house ist nicht automatisch unabhängig. Wenn nur eine Person das Deployment versteht, alle Cloud-Zugänge besitzt oder zentrale Entscheidungen im Kopf hält, entsteht ebenfalls Lock-in — nur gegenüber einem Mitarbeiter statt gegenüber einem Dienstleister. Repository-Zugriff, Runbooks, Reviews und dokumentierte Entscheidungen bleiben deshalb auch intern notwendig.
Wann eine Engineering-Partnerschaft sinnvoll ist
Ein Partner kann die stärkere Wahl sein, wenn der Bedarf klar begrenzt oder die benötigte Erfahrung nicht dauerhaft auszulasten ist:
- ein neuer Produkt- oder Plattform-Workflow soll end-to-end gebaut werden;
- ein Legacy-System muss schrittweise modernisiert werden;
- Architektur, API-, DevOps- oder Performance-Kompetenz wird für eine konkrete Phase benötigt;
- das interne Team kann Produktentscheidungen treffen, aber nicht gleichzeitig alle Delivery-Risiken tragen;
- ein späteres internes Team ist geplant, soll jedoch nicht vor einem verstandenen System eingestellt werden;
- eine bestehende Plattform braucht Stabilisierung, Dokumentation und einen geordneten Übergang.
Eine Engineering-Partnerschaft ist mehr als Staff Augmentation, wenn der Partner nicht nur Stunden bereitstellt, sondern definierte Lieferobjekte, technische Entscheidungen, Qualitätssicherung und Übergabe verantwortet. Bleiben Priorisierung, Architektur, Abnahme und Betrieb ungeklärt, ist „Partnerschaft“ lediglich ein Marketinglabel.
Warum das Hybridmodell oft belastbarer ist
Bei einem Hybridmodell bleibt mindestens eine entscheidungsfähige Produkt- oder Technikrolle intern. Der externe Partner übernimmt einen klaren Teil der Umsetzung und bringt zusätzliche Senior-Kompetenz ein. Mit zunehmender interner Kapazität verschiebt sich die Grenze.
Ein mögliches Zielbild:
| Verantwortung | Intern | Gemeinsam | Partner |
|---|---|---|---|
| Produktziel und Priorisierung | ✓ | ||
| Fachliche Regeln und Abnahme | ✓ | ✓ | |
| Architekturentscheidungen | ✓ | ||
| Implementierung einer gescopten Phase | ✓ | ||
| Code Review und Qualitätskriterien | ✓ | ||
| Repository und Cloud-Accounts | ✓ | ✓ | |
| Dokumentation und Runbooks | ✓ | ||
| Betrieb nach vollständiger Übergabe | ✓ | ✓ |
Die Tabelle ist kein Standardvertrag. Sie zeigt, welche Entscheidungen explizit werden müssen. In einem anderen Unternehmen kann Betrieb dauerhaft extern bleiben oder Architektur vollständig intern liegen.
TCO richtig vergleichen: Jahresgehalt ist nicht gleich Partnerrechnung
Der häufigste Rechenfehler ist der Vergleich eines Bruttojahresgehalts mit zwölf Partnerrechnungen. Beide Zahlen enthalten unterschiedliche Leistungen und Risiken. Verwenden Sie stattdessen dieselbe Betrachtungsperiode und rechnen Sie nur mit eigenen, belegbaren Werten.
TCO eines In-house-Modells
| Kostenblock | Eigener Eingabewert |
|---|---|
| Bruttovergütung | Vertraglicher Jahreswert |
| Arbeitgeberanteile und Benefits | Werte aus Payroll/Finance |
| Recruiting | Anzeigen, Vermittlung, Interviewzeit, ggf. Relocation |
| Arbeitsplatz | Hardware, Software, Lizenzen, Weiterbildung |
| Führung und Enablement | Onboarding, Reviews, 1:1, Architektur- und Produktsteuerung |
| Vakanz- und Ausfallrisiko | Nur mit intern nachvollziehbarer Annahme rechnen |
| Vertretung und Betrieb | On-call, Urlaub, Krankheit, Bus-Factor-Absicherung |
TCO einer Engineering-Partnerschaft
| Kostenblock | Eigener Eingabewert |
|---|---|
| Vereinbarte Delivery-Phasen | Scope, Deliverables und Abnahmekriterien |
| Discovery und Onboarding | Systemzugang, Domänenwissen, Datenflüsse |
| Interne Steuerung | Product Owner, fachliche Abnahme, Entscheidungen |
| Laufender Betrieb | Nur falls tatsächlich Teil des Mandats |
| Transition und Handover | Dokumentation, Training, Zugänge, Rest-Risiken |
| Change-Budget | Neue Erkenntnisse außerhalb des vereinbarten Scope |
Vergleichen Sie anschließend nicht nur die Summe, sondern drei weitere Größen:
- nutzbare Kapazität: Wie viel der Zeit steht tatsächlich für die priorisierte Arbeit zur Verfügung?
- Entscheidungsabdeckung: Wer löst Architektur-, Security- und Betriebsfragen?
- Restwert nach zwölf Monaten: Welcher Code, welches Wissen und welche betriebliche Fähigkeit bleiben im Unternehmen?
So kann ein Partner in einer Build-Phase wirtschaftlich sein, obwohl sein Tagessatz höher aussieht. Umgekehrt kann ein internes Team langfristig klar günstiger sein, wenn der Bedarf stabil ist und Führung, Betrieb sowie Wissenstransfer bereits funktionieren. Ohne Ihre Zahlen ist keine der beiden Aussagen seriös verallgemeinerbar.
Ein 12-Monats-Plan statt einer abstrakten Grundsatzentscheidung
Treffen Sie die Entscheidung entlang der erwarteten Produktphasen:
| Phase | Zentrale Frage | Mögliches Modell |
|---|---|---|
| Monat 0–2: Scope und Architektur | Ist das Problem ausreichend verstanden, um Rollen sinnvoll zu besetzen? | Kleine interne Führung plus begrenzter Architecture-/Discovery-Scope |
| Monat 2–6: erster Build | Welche Kompetenzen werden gleichzeitig benötigt und welche bleiben später? | Partner für gescopte Delivery oder Hybridteam |
| Monat 5–9: Stabilisierung | Wer übernimmt Monitoring, Incidents, Backups und Release-Prozess? | Gemeinsamer Betrieb mit dokumentierter Verantwortungsverschiebung |
| Monat 8–12: Ausbau | Ist genug kontinuierlicher Arbeitsvorrat für interne Rollen vorhanden? | Gezielt intern einstellen, Partner reduzieren oder für Spezialthemen behalten |
Das verhindert zwei teure Gegenfehler: zu früh ein Team für ein noch unbekanntes System einzustellen oder einen externen Partner ohne Exit-Modell dauerhaft zum einzigen Wissensträger zu machen.
Governance, Sicherheit und Datenschutz bleiben beim Auftraggeber steuerbar
Outsourcing verschiebt Aufgaben, nicht automatisch die Gesamtverantwortung. Der BSI-Baustein OPS.2.3 „Nutzung von Outsourcing“ betrachtet Informationssicherheit deshalb über den gesamten Outsourcing-Lebenszyklus — von Strategie und Auswahl bis Steuerung und Beendigung.
Wenn ein Partner personenbezogene Daten im Auftrag verarbeitet, kann zusätzlich Art. 28 DSGVO relevant sein. Ob eine Auftragsverarbeitung vorliegt und welche Vertragsregelung nötig ist, muss für das konkrete Setup geprüft werden. Technisch sollten mindestens Datenflüsse, Zugriffsrechte, Unterauftragnehmer, Logging, Löschung und der Exit-Weg sichtbar sein.
Unabhängig vom Modell gehören diese Punkte in die Governance:
- ein benannter Owner für Produkt, Architektur und Betrieb;
- Repository und produktionsrelevante Accounts unter kontrollierbarem Unternehmenszugriff;
- dokumentierte Berechtigungen und regelmäßige Access Reviews;
- ein nachvollziehbarer Change-, Review- und Abnahmeprozess;
- Incident- und Eskalationswege;
- ein Exit- und Handover-Paket, das nicht erst bei Kündigung erfunden wird.
Was ein belastbares Handover enthalten sollte
Ein Übergabepfad ist kein Zeichen dafür, dass die Partnerschaft kurz sein muss. Er ist die Bedingung dafür, dass sie freiwillig bleibt.
Mindestens erwartet werden sollten:
- Repository samt History und verständlicher Branch-/Release-Logik;
- Systemübersicht, Datenmodell und relevante Architecture Decision Records;
- Umgebungs-, Deployment-, Backup- und Recovery-Anleitung;
- Verzeichnis der Accounts, Domains, Provider, Secrets und Verantwortlichen;
- API-Verträge und Integrationsabhängigkeiten;
- bekannte technische Schulden, Risiken und offene Entscheidungen;
- gemeinsamer Dry Run für Setup, Deployment oder Incident-Ablauf;
- definierte Phase für Wissenstransfer an neue interne Verantwortliche.
Die vollständige Auswahl- und Vertragscheckliste finden Sie im Beitrag „Softwareagentur in Deutschland auswählen: 12 Fragen vor dem Vertrag“.
Welche Nachweise wirklich helfen
Fragen Sie nicht nur nach Logos oder Aussagen wie „langfristiger Partner“. Nützlicher sind Artefakte und klar abgegrenzte Lieferkontexte:
- Wie sieht ein anonymisiertes Decision Log aus?
- Welche Teile eines Runbooks werden standardmäßig geliefert?
- Wie wird eine Rollen- oder Tenant-Grenze abgenommen?
- Wer besitzt Repository, Cloud-Accounts und Deployment-Pipeline?
- Wie wird ein Übergabe-Dry-Run dokumentiert?
H-Studio veröffentlicht beispielsweise technische Systemkontexte zu Vulken FM und My Office Asia. Diese Referenzen zeigen gelieferte Plattform- und Workflow-Komplexität. Sie sind kein Beleg für pauschale Kosteneinsparungen, eine bestimmte Teamform oder garantierte Geschäftsergebnisse.
Wann H-Studio nicht der richtige Partner ist
H-Studio passt nicht gut, wenn:
- Sie ausschließlich einzelne Entwickler unter täglicher interner Aufgabensteuerung benötigen;
- ein dauerhaftes Großteam für ein Enterprise-Programm gestellt werden soll;
- der Scope ein bewusst wegwerfbarer Prototyp ohne Produktionsanforderungen ist;
- Sie primär den niedrigsten kurzfristigen Stundensatz suchen;
- Produktpriorisierung und fachliche Abnahme intern niemand übernehmen kann;
- ein bestehendes internes Team die benötigte Kapazität und Kompetenz bereits zuverlässig abdeckt.
In diesen Fällen können eine interne Einstellung, ein spezialisierter Freelancer, ein Team-Extension-Anbieter oder eine größere Beratung passender sein.
H-Studio passt eher zu einem klar abgrenzbaren Produkt-, Plattform- oder Modernisierungsvorhaben, bei dem Senior Engineering, Architekturentscheidungen, dokumentierte Delivery und ein späterer Übergabepfad zusammengehören. Mögliche Einstiege sind ein begrenzter MVP-Build, individuelle Softwareentwicklung oder die Stabilisierung und Übergabe einer bestehenden Plattform über Platform Support & Maintenance.
Praktische Entscheidungscheckliste
Beantworten Sie vor Budgetfreigabe diese zehn Fragen:
- Welcher konkrete Engpass soll gelöst werden: Kapazität, Kompetenz oder Führung?
- Welche Arbeit bleibt nach dem aktuellen Build mindestens zwölf Monate bestehen?
- Wer priorisiert Produkt und nimmt fachlich ab?
- Wer trägt Architektur- und Betriebsentscheidungen?
- Welche Rollen lassen sich intern tatsächlich beurteilen und onboarden?
- Welche Accounts, Daten und Systeme berührt das Vorhaben?
- Welche Deliverables müssen nach drei, sechs und zwölf Monaten vorliegen?
- Wie sieht der Kostenvergleich mit identischer Betrachtungsperiode aus?
- Wie werden Wissen, Repository und Betrieb übergeben?
- Unter welchen Bedingungen wird das Modell vergrößert, reduziert oder beendet?
Wenn drei oder mehr Antworten offen bleiben, ist nicht die Teamform das erste Problem. Dann fehlt zunächst ein belastbarer Scope und ein Verantwortungsmodell.
Häufige Fragen
Ist eine Engineering-Partnerschaft günstiger als ein In-house-Team?
Nicht pauschal. Ein Partner kann für eine begrenzte Build- oder Modernisierungsphase wirtschaftlicher sein, weil mehrere Kompetenzen nur zeitweise benötigt werden. Bei dauerhaft stabiler Auslastung kann ein internes Team langfristig günstiger sein. Vergleichen Sie über denselben Zeitraum Vergütung, Recruiting, Führung, Betrieb, interne Steuerung und Handover — nicht Gehalt gegen Tagessatz.
Wann sollte ein Unternehmen Entwickler fest einstellen?
Wenn Software dauerhaft zum Kerngeschäft gehört, ein kontinuierlicher Arbeitsvorrat besteht und technische Führung Kandidaten beurteilen sowie das Team wirksam einsetzen kann. Eine Stelle sollte aus dem langfristigen Zielbild entstehen, nicht nur aus dem Druck eines einzelnen Launches.
Was ist der Unterschied zwischen Engineering-Partnerschaft und Staff Augmentation?
Staff Augmentation stellt vor allem Kapazität in einem vom Kunden geführten Prozess bereit. Eine Engineering-Partnerschaft übernimmt zusätzlich klar definierte Delivery-, Architektur- oder Qualitätsverantwortung. Entscheidend ist nicht das Label, sondern was im Scope, in den Entscheidungsrechten und in den Abnahmekriterien steht.
Kann ein Partner später an ein internes Team übergeben?
Ja, wenn die Übergabe von Anfang an eingeplant ist. Repository und Accounts sollten kontrollierbar sein; Architektur, Betrieb und offene Risiken müssen dokumentiert werden. Sinnvoll sind gemeinsames Arbeiten, schrittweise Verantwortungsverschiebung und ein praktischer Deployment- oder Recovery-Dry-Run vor Abschluss.
Wer sollte im Hybridmodell intern bleiben?
Mindestens Produktpriorisierung und fachliche Abnahme benötigen eine entscheidungsfähige interne Verantwortung. Je nach Produkt sollten auch technische Führung, Security oder Betrieb intern liegen. Ein externer Partner kann Rollen zeitweise unterstützen, aber die geschäftliche Produktverantwortung nicht ersetzen.
Wie startet man mit geringem Risiko?
Mit einem begrenzten Scope, echten Artefakten und einer klaren Entscheidungsstelle danach. Das kann eine Architekturphase, ein End-to-End-Workflow oder die Stabilisierung eines bestehenden Systems sein. Prüfen Sie dabei nicht nur Code, sondern Kommunikation, Decision Log, Dokumentation, Abnahme und Übergabefähigkeit.
Quellen und Stand
- Bundesagentur für Arbeit: Fachkräfteengpassanalyse 2025, veröffentlicht 2026
- Bundesagentur für Arbeit: Arbeitsmarkt für IKT-Berufe, Stand Juni 2026
- Statistisches Bundesamt: IT-Fachkräfte und Besetzungsschwierigkeiten, abgerufen Juli 2026
- BSI IT-Grundschutz OPS.2.3: Nutzung von Outsourcing
- Datenschutz-Grundverordnung, insbesondere Art. 28
Stand: 17. Juli 2026. Fachlich und redaktionell geprüft von Anna Hartung. Rechtliche Hinweise dienen der technischen Projektorientierung und ersetzen keine Rechtsberatung.