Warum interne Entwicklerteams bei operativen Kernsystemen scheitern
Inhouse Entwicklung vs Agentur: ein struktureller Leitfaden fuer B2B-Dienstleister im DACH-Raum mit 10 bis 50 Mio. Umsatz
Table of Contents
Die Frage Inhouse Entwicklung vs Agentur erscheint auf den ersten Blick klar, bis man mittendrin steckt. Unternehmen im DACH-Raum mit 10 bis 50 Mio. Umsatz, Logistiker, Spezialvermieter, operative B2B-Dienstleister, erreichen irgendwann einen Punkt, an dem ihre Betriebssysteme nicht mehr auf SaaS-Tools und Tabellen laufen koennen. Etwas muss gebaut werden. Und der erste Impuls ist fast immer: Wir stellen einen Entwickler ein.
Das ist ein nachvollziehbarer Impuls. Das Budget fuer ein oder zwei Entwickler ist vorhanden. Man will Kontrolle. Man will jemanden, der das Unternehmen versteht. Und die Erfahrungen mit Agenturen, die das Falsche bauen, sind verbreitet genug, dass eine interne Loesung sicherer erscheint.
Fuer die meisten Unternehmen auf dieser Umsatzstufe stossen interne Entwicklerteams beim Aufbau operativer Kernsysteme jedoch auf spezifische, strukturelle Grenzen. Nicht wegen schlechter Personalentscheidungen, nicht wegen mangelnder Engineering-Qualitaet. Weil die Kombination an Faehigkeiten, die ein Betriebssystem wirklich braucht, selten das ist, was ein internes Entwicklerteam dieser Groesse strukturell bereitstellen kann.
Dieser Artikel beschreibt diese Grenzen klar, damit die Entscheidung ueber den Aufbau der eigenen Betriebsinfrastruktur auf der richtigen Grundlage getroffen wird.
Die Umsatzstufe, bei der Standardratschlaege nicht mehr greifen
Die meisten Ratschlaege zu Inhouse Entwicklung vs Agentur sind fuer zwei Zielgruppen geschrieben: fruehphasige Startups, die ein MVP validieren, und grosse Konzerne, die komplexe Engineering-Organisationen steuern. Das mittelstaendische Unternehmen mit 10 bis 50 Mio. Umsatz sitzt zwischen diesen beiden Welten, und die Standardempfehlungen passen nicht.
Auf dieser Stufe ist das Unternehmen kein Startup mehr. Der Betrieb ist real, komplex und laeuft unter echtem kommerziellem Druck. Es werden reale Auftraege verarbeitet, reale Bestaende verwaltet, reale Kunden bedient, mit Servicelevel-Erwartungen, die nicht verfehlt werden duerfen. Die operativen Einsaetze sind hoch.
Aber das Unternehmen ist auch kein Konzern. Es kann kein zehnkoepfiges Engineering-Team tragen. Ein Vollzeit-CTO, ein Business-Architect, zwei Senior-Entwickler, ein QA-Lead und ein DevOps-Engineer, das Budget reicht fuer einen oder zwei Entwickler, nicht fuer eine Abteilung.
Genau dieser Engpass, echte operative Komplexitaet bei begrenzter Engineering-Kapazitaet, macht die Frage Inhouse Entwicklung vs Agentur schwieriger als sie scheint, und einen Fehler darin teuer.
Was Betriebssysteme wirklich brauchen, und warum das sich von Produktentwicklung unterscheidet
Bevor Inhouse vs Agentur bewertet wird, lohnt es sich zu klaeren, welche Art von Problem hier eigentlich geloest werden soll. Es gibt einen bedeutenden Unterschied zwischen dem Bau eines Produkts und dem Bau eines Betriebssystems, und das jeweils erforderliche Faehigkeitsprofil ist verschieden.
Produktentwicklung
Ein Produkt ist Software, die das Unternehmen verkauft oder die definiert, wie Kunden die Dienstleistung erleben. Es muss gut engineert, skalierbar und haeufig auf Basis von Nutzerfeedback weiterentwickelt werden. Inhouse-Entwicklung kann hier die richtige Wahl sein, wenn sie ausreichend finanziert ist, weil das Team ueber Zeit tiefes Produktwissen aufbaut und kontinuierlich iterieren kann.
Aufbau eines Betriebssystems
Ein Betriebssystem ist Software, die interne Unternehmensprozesse steuert. Angebotserstellung, Disposition, Bestandszuteilung, Ausnahmenbearbeitung, Kundenaufnahme. Es muss die operative Realitaet des spezifischen Unternehmens abbilden, die eigene Preislogik, die eigenen Ausnahmetypen, die eigene Datenstruktur, die eigenen Integrationsbedingungen.
Dieser Unterschied ist entscheidend, weil Betriebssysteme am Anfang einen anderen Input benoetigen: jemanden, der versteht, wo im Ist-Prozess Wert verloren geht, bevor die erste Zeile Code geschrieben wird. Das ist keine Entwicklerfaehigkeit. Es ist eine Business-Architektur-Faehigkeit. Und auf der Umsatzstufe von 10 bis 50 Mio. haben interne Entwicklerteams sie fast nie eingebaut.
Der haeufigste und teuerste Fehler auf dieser Umsatzstufe ist, ein internes Entwicklerteam damit zu beauftragen, ein Betriebssystem nach einer Spezifikation zu bauen, die von Betriebsmitarbeitern geschrieben und von einem Entwickler geprueft wurde. Das Ergebnis ist Software, die technisch korrekt und operativ falsch ausgerichtet ist. Sie automatisiert den dokumentierten Prozess, nicht den optimalen.
Fuenf strukturelle Herausforderungen interner Entwicklerteams auf der 10 bis 50 Mio. Umsatzstufe
Die folgenden Herausforderungen betreffen nicht die Qualitaet der eingestellten Entwickler. Sie sind strukturell, eine Folge dessen, was ein zwei- bis dreikoepfiges internes Team auf dieser Umsatzstufe ist und nicht ist.
Die strukturelle Herausforderung | Warum besseres Hiring das nicht loest |
|---|---|
Kein Wettbewerb um Senior-Entwickler moeglich | Tech-Unternehmen zahlen das Zwei- bis Dreifache. Das Budget fehlt. |
Wartung verdraengt Neuentwicklung | Betriebssysteme erzeugen Supportlast. Neuprojekte stocken. |
Entwicklung nach Spezifikation, nicht nach Ergebnis | Ohne Business-Architektur driftet das System vom P&L weg. |
Domainwissen braucht 6 bis 12 Monate | Operative Praezision erfordert Branchenkenntnis, nicht nur Code. |
Ein Abgang setzt das Projekt zurueck | Im kleinen Team gibt es keine Redundanz. Wissen geht verloren. |
Herausforderung 1: Kein Wettbewerb um Senior-Entwickler
Der Aufbau eines operativen Kernsystems erfordert Senior-Engineering. Junior-Entwickler bauen, was ihnen gesagt wird, haeufen technische Schulden schneller an als sie abbauen und benoetigen Supervision, die auf dieser Unternehmensebene typischerweise nicht vorhanden ist. Senior-Entwickler auf dem fuer komplexe Betriebssysteme erforderlichen Niveau verdienen im DACH-Markt 90.000 bis 140.000 EUR, und Tech-Unternehmen sowie finanzierte Startups konkurrieren um dieselben Profile mit Eigenkapital, Flexibilitaet und besserer Infrastruktur. Ein Logistikunternehmen mit 30 Mio. Umsatz ist in diesem Markt kein bevorzugter Arbeitgeber.
Die praktische Folge ist, dass interne Entwicklerteams auf dieser Stufe haeufig mit Entwicklern enden, die entweder ueberqualifiziert und nach 18 Monaten wieder weg sind, oder junior genug, um erschwinglich zu sein, aber nicht ausreichend fuer die Komplexitaet der Aufgabe. Keines der beiden Ergebnisse liefert, was das Unternehmen braucht.
Herausforderung 2: Wartung verdraengt Neuentwicklung
Sobald ein Betriebssystem, oder auch nur ein Teil davon, in Betrieb ist, erzeugt es eine Supportlast. Fehler treten auf. Randfaelle entstehen. Nutzer beantragen Aenderungen. Datenmigration findet statt. Schnittstellen brechen. Fuer ein ein- bis zweikoepfiges internes Team konkurriert diese laufende Wartungsverantwortung direkt mit der Neuentwicklungskapazitaet. Innerhalb von zwoelf Monaten nach Go-live stellen viele interne Teams fest, dass 60 bis 70 Prozent ihrer Zeit von Wartung und Support bestehender Systeme absorbiert werden, und 30 Prozent oder weniger fuer Neubauten bleiben.
Das ist kein Planungsfehler. Das ist das, was operative Software tut. Die Frage ist, ob das interne Team gross genug ist, das aufzufangen, ohne den Fahrplan zum Stillstand zu bringen. Auf dieser Umsatzstufe ist es das selten.
Herausforderung 3: Entwickler bauen nach Spezifikation, nicht nach Ergebnis
Ohne Business-Architect im Team wird das Entwicklungsbriefing typischerweise von der Person geschrieben, die dem Problem am naechsten ist: ein Betriebsleiter, ein COO oder der Gruender selbst. Dieses Briefing beschreibt den aktuellen Prozess, nicht den optimalen. Es dokumentiert, wie Dinge heute gemacht werden, einschliesslich der Ineffizienzen, der Workarounds und der manuellen Schritte, die sich ueber Jahre angesammelt haben.
Ein Entwickler, der nach dieser Spezifikation arbeitet, baut, was die Spezifikation beschreibt. Das Ergebnis ist ein System, das einen bestehenden fehlerhaften Prozess automatisiert, anstatt ihn durch einen besseren zu ersetzen. Die Automatisierung ist technisch erfolgreich. Die operative Verbesserung ist marginal. Die Moeglichkeit, die die Investition rechtfertigte, schnellerer Durchsatz, bessere Margen, geringere Schluesselpersonabhaengigkeit, wird nicht genutzt.
Herausforderung 4: Domainwissen braucht Zeit, die der Fahrplan nicht hat
Operative Praezision in einem Logistikunternehmen, einem Spezialvermietbetrieb oder einem komplexen B2B-Dienstleister erfordert Branchenkenntnis, nicht nur Codekenntnis. Wie Preisausnahmen funktionieren. Was eine nicht standardmaessige Disposition ausloest. Wie kundenspezifische Vereinbarungen den Standardprozess beeinflussen. Wie Marge tatsaechlich kalkuliert wird, verglichen mit dem, was auf dem Papier steht.
Ein interner Entwickler baut dieses Wissen ueber Zeit auf, typischerweise sechs bis zwoelf Monate, bevor er Systeme bauen kann, die es zuverlaessig abbilden. In diesem Zeitfenster basiert das, was gebaut wird, auf dem, was erzaehlt wurde, nicht auf dem, was beobachtet wurde. Der Unterschied zeigt sich oft in den ersten sechs Monaten des Live-Betriebs, wenn Randfaelle auftauchen, die die Spezifikation nie erfasst hat, weil der Entwickler noch nicht wusste, danach zu fragen.
Herausforderung 5: Ein Abgang setzt das Projekt zurueck
Bei einem zwei- bis dreikoepfigen internen Entwicklerteam ist ein einzelner Abgang keine Kapazitaetsreduzierung. Es ist ein Projektzuruecksetzen. Der Entwickler, der das System gebaut hat, nahm die Architekturentscheidungen, die nicht dokumentierte Logik und das Integrationswissen mit. Was bleibt, ist eine Codebase, die das verbleibende Team, oder dessen Nachfolger, rueckentwickeln muss, bevor der Weiterbau moeglich ist.
Das ist kein Dokumentationsfehler, auch wenn bessere Dokumentation hilft. Es ist eine strukturelle Folge kleiner Teamgroesse. Es gibt keine Redundanz. Es gibt keine zweite Person, die dieselben Entscheidungen getroffen hat und dasselbe Wissen haelt. Das Schluesselpersonrisiko ist absolut, nicht marginal.
Inhouse Entwicklung vs Agentur: Was der Vergleich wirklich zeigt
Wenn Unternehmen zu dem Schluss kommen, dass internes Entwicklerteam Grenzen hat, ist die naechste Frage meist die Agentur. Aber die uebliche Gegenueberteilung Inhouse Entwicklung vs Agentur uebersieht die wichtigste Variable: welche Art von Agentur, und welches Briefing bekommt sie.
Eine generische Softwareentwicklungsagentur loest das Hiring- und Headcount-Problem. Sie loest das Business-Architektur-Problem nicht. Die meisten Agenturen nehmen eine Spezifikation entgegen und bauen danach. Die Spezifikation wird weiterhin von Betriebsmitarbeitern geschrieben. Die Domainluecke bleibt bestehen. Das System riskiert weiterhin, technisch korrekt und operativ falsch ausgerichtet zu sein. Die Agentur liefert schneller und mit mehr Engineering-Disziplin, aber zum selben falschen Briefing.
Der Vergleich, der auf dieser Stufe wirklich zaehlt, ist nicht internes Entwicklerteam versus generische Agentur. Er liegt zwischen jedem Modell, das mit einem Entwickler beginnt, und jedem Modell, das mit einem Business-Architekten beginnt, der gemeinsam mit einem Entwickler arbeitet.
Faktor | Internes Entwicklerteam | Operativer Optimierungspartner |
|---|---|---|
Erste Ergebnisse | 4 bis 9 Monate (Hiring + Onboarding) | 4 bis 8 Wochen (Audit + Scope) |
Domainwissen | Baut sich langsam auf, beginnt bei null | Wird vom ersten Tag eingebracht |
Business-Architektur | Im Team selten vorhanden | Fest mit Engineering gekoppelt |
Kostenstruktur | Fix, unabhaengig vom Output | Projektbasiert, an Lieferung gebunden |
Schluesselpersonrisiko | Hoch, ein Abgang blockiert den Fahrplan | Verteilt, Teamkontinuitaet eingebaut |
KI-Integration | Moeglich, abhaengig von Teamskills | Ab der Prozessschicht mitgeplant |
Richtig fuer | Kernproduktentwicklung in grossem Massstab | Betriebssysteme bei 10 bis 50 Mio. Umsatz |
Wann internes Entwicklerteam die richtige Wahl ist
Interne Entwicklerteams sind in bestimmten Situationen wirklich die richtige Wahl. Wenn Ihre Software Ihr Kernprodukt ist, das, wofuer Kunden zahlen, baut internes Entwicklerteam die tiefe Produktkenntnis und Iterationsgeschwindigkeit auf, die extern in diesem Massstab nicht reproduziert werden kann. Bei mehr als 50 Mio. Umsatz und einem tragfaehig strukturierten Engineering-Team mit Senior-Fuehrung werden die Fixkosten eines internen Teams im Vergleich zu externen Alternativen wettbewerbsfaehig. Wenn der Entwicklungsfahrplan kontinuierlich und mehrjaehrig ist, ist das institutionelle Wissen, das sich in einem internen Team aufbaut, ein echter Vermoegenswert.
Fuer operative B2B-Dienstleister mit 10 bis 50 Mio. Umsatz, deren Kernprodukt die Dienstleistung und nicht die Software ist, treffen diese Bedingungen selten alle gleichzeitig zu.
Die dritte Option, die die meisten Inhouse-vs.-Agentur-Vergleiche nicht nennen
Die Gegenueberteilung Inhouse Entwicklung vs Agentur stellt zwei Optionen vor. Es gibt eine dritte. Fuer Betriebssysteme auf dieser Umsatzstufe ist sie typischerweise die am besten geeignete: ein operativer Optimierungspartner, der Business-Architektur und Engineering von Anfang an koppelt.
Der Unterschied ist kein Marketing-Vokabular. Es ist ein struktureller Unterschied darin, wie das Engagement beginnt. Eine Standard-Agentur beginnt mit einem Anforderungsgespraech, das eine Spezifikation produziert, dann wird danach gebaut. Ein operativer Optimierungspartner beginnt mit einem Wertketten-Audit, der erfasst, wo Zeit und Marge tatsaechlich verloren gehen, produziert ein Prozessdesign vor jeder Zeile Code, und geht erst dann in den Bau, mit einem Ingenieur, der nach diesem Design arbeitet, gemeinsam mit dem, der es erstellt hat.
Wie das in der Praxis aussieht
Ein Logistikunternehmen mit 25 Mio. EUR Umsatz hatte zweimal versucht, ein eigenes Angebotsystem zu bauen, einmal mit einem freien Entwickler, einmal mit einer mittelgrossen Agentur. Beide Male wurde das System geliefert und war innerhalb von sechs Monaten teilweise zugunsten von Excel-Workarounds aufgegeben worden. Die Angebotslogik war komplexer als beide Projekte erfasst hatten, und keines der Engagements hatte jemanden einbezogen, der mit genuegend operativer Vertrautheit die Luecke haette erkennen koennen, bevor sie ins System eingebaut wurde.Das dritte Engagement begann mit einem zweiwoechigen Prozess-Audit. Der Audit identifizierte vier Preisausnahmetypen, die 40 Prozent des Angebotsvolumens ausmachten und nirgendwo dokumentiert waren. Das System wurde um diese Ausnahmen herum konzipiert, nicht als Randfaelle, sondern als Kernprozessverlaeufe. Es ging termingerecht live, wurde innerhalb von acht Wochen vollstaendig uebernommen und eliminierte die Excel-Workarounds vollstaendig.
Der Unterschied war nicht besseres Engineering im dritten Engagement. Die Engineering-Qualitaet war vergleichbar mit dem zweiten. Der Unterschied war, dass jemand mit operativer Expertise den Prozess erfasst hatte, bevor der Ingenieur mit dem Bauen begann, und entdeckte, was zwei vorherige Spezifikationen uebersehen hatten.
Wie appleute auf der 10 bis 50 Mio. Umsatzstufe arbeitet
appleute ist operativer Optimierungspartner fuer B2B-Dienstleister im DACH-Raum, deren Betriebsprozesse ueber ihre bisherige Infrastruktur hinausgewachsen sind. Wir sind keine generelle Softwareentwicklungsagentur. Wir arbeiten gezielt mit Unternehmen, bei denen die Luecke zwischen operativer Komplexitaet und aktuellen Systemen messbare Marge und Durchsatz kostet.
Das Dual-Lead-Modell
Jedes Engagement koppelt einen Senior Business Architect mit einem Lead Engineer. Der Business Architect verantwortet das operative Design: Wertverluste erfassen, den Prozess mit der groessten Hebelwirkung identifizieren, den Ablauf neu konzipieren, bevor Code geschrieben wird. Der Lead Engineer verantwortet den technischen Bau: dieses Design in ein System uebersetzen, das in die bestehende Infrastruktur integriert und nach der Lieferung gewartet und weiterentwickelt werden kann.
Das ist der strukturelle Unterschied zu sowohl internem Entwicklerteam als auch Standard-Agenturen. Das Engineering arbeitet nicht nach einer Spezifikation, die von einem Betriebsleiter geschrieben wurde. Es arbeitet nach einem operativen Design, das von jemandem erstellt wurde, dessen Hauptaufgabe es ist zu verstehen, wie B2B-Dienstleistungsbetriebe Wert schaffen und vernichten.
Was wir nicht tun
Wir nehmen keine Spezifikation entgegen und bauen danach. Wir bauen keine MVPs ohne vorheriges Prozessdesign. Wir konkurrieren nicht ueber Stundenloehne. Wir nehmen keine Mandate an, bei denen SaaS das Problem loest. Wenn es eine Standardloesung gibt, die passt, sagen wir das, bevor ein Projekt beginnt.
Der Einstiegspunkt
Jedes Engagement beginnt mit einem Strategischen Audit: ein festpreislicher, eigenstaendiger Tiefen-Dive in den operativen Prozess, in dem Reibung und Kosten am staerksten konzentriert sind. Der Audit produziert ein Prozessdesign und eine Roadmap zur Kostenneutralitaet, bevor ein Bauauftrag erteilt wird. Unternehmen, die durch einen gescheiterten internen Entwicklung- oder Agenturauftrag gegangen sind, finden den Audit typischerweise am wertvollsten: er zeigt praezise, was das vorherige Engagement uebersehen hat, und warum.
Was jetzt zu tun ist
Wenn Sie gerade debattieren, ob Sie einen Entwickler einstellen, Ihr internes Team erweitern oder mit einem externen Partner zusammenarbeiten sollen, um ein operatives Kernsystem zu bauen: der nuetzlichste erste Schritt ist keine Software-Entscheidung. Es ist eine Prozessentscheidung.
Beginnen Sie damit, drei Fragen zu beantworten. Welcher einzelne operative Ablauf haette die groesste Wirkung auf Ihre Margen, wenn er zuverlaessig und ohne manuelle Eingriffe liefe? Wo in diesem Prozess lebt die meiste Zeit und der groesste Koordinationsaufwand? Und ist das Problem, dass ein System fehlt, oder dass die vorhandenen Systeme nicht abbilden, wie die Arbeit tatsaechlich fliesst?
Diese drei Antworten sagen Ihnen mehr ueber den richtigen Bauansatz als jeder Vergleich von Stundenloehnen oder Teamstrukturen. In den meisten Faellen zeigen sie ausserdem, dass das Problem kleiner und adressierbarer ist als es anfaenglich erschien: ein Prozess, gut konzipiert und richtig gebaut, erzeugt typischerweise in sechs Monaten mehr Wirkung als ein vollstaendiges internes Entwicklerteam im gleichen Zeitraum.
In einem kurzen Discovery-Gespraech erfassen wir den Prozess, in dem operative Reibung konzentriert ist, beurteilen, ob die Einschraenkung ein Design- oder ein Bauproblem ist, und geben Ihnen eine klare Einschaetzung, ob ein operativer Optimierungsauftrag auf Ihrer aktuellen Stufe sinnvoll ist. Keine Verpflichtung erforderlich. Eine konkrete Einschaetzung Ihrer Situation.
Wenn Sie diese externe Perspektive wuenschen: Wir sind bereit.
Vereinbaren Sie einen kostenlosen und unverbindlichen Beratungstermin mit unserem Team.
DE 
EN 
FR 
ES