„Wir entwickeln das lieber selbst.“ Dieser Satz leitet seit 25 Jahren viele Gespräche über Softwareprojekte ein. Der Wunsch dahinter ist nachvollziehbar: volle Kontrolle über die eigene Software, kurze Wege, kein externer Dienstleister, der den Geschäftskontext erst verstehen muss.

Häufig scheitert die Umsetzung dieses Wunsches aber an Voraussetzungen, die unterschätzt werden.

Das typische Szenario

Ein Unternehmen hat einen Entwickler, vielleicht zwei. Die kümmern sich um die Website, das ERP-Customizing, ein paar Schnittstellen. Nebenbei betreuen sie Teile der internen IT. Das funktioniert, solange die Aufgaben überschaubar bleiben.

Dann kommt ein neues Projekt dazu: Eine Fachanwendung, die einen echten Geschäftsprozess abbilden soll. Plötzlich verändert sich die Situation grundlegend.

Der Entwickler arbeitet allein. Niemand prüft seine Arbeit, niemand hinterfragt Architekturentscheidungen. Nicht aus mangelndem Willen, sondern weil schlicht kein zweiter Fachmensch da ist, der das leisten könnte.

Die Fachabteilung wartet Wochen auf Änderungen, weil der Entwickler parallel drei andere Baustellen betreut. Nach 18 Monaten ist er überlastet und kündigt. Zurück bleibt Software, die niemand im Unternehmen versteht, warten oder weiterentwickeln kann.

Das ist keine Kritik an dem Entwickler. Er macht unter den gegebenen Umständen einen guten Job. Aber ein Entwickler allein ist kein Softwareteam. Genauso wie ein Chirurg allein kein OP-Team ist.

Zwei Bedeutungen von „Wir machen das selbst“

Hinter dem Satz „Wir entwickeln das selbst“ verbergen sich tatsächlich zwei sehr unterschiedliche Ansätze.

Ein professionelles internes Team aufbauen: Das bedeutet: Mehrere Entwickler mit komplementären Fähigkeiten. Etablierte Prozesse für Qualitätssicherung, Tests und Deployment. Vertretungsregelungen. Kontinuierliche Weiterbildung. Das ist der richtige Weg, aber er erfordert eine erhebliche Investition. Für ein funktionsfähiges internes Softwareteam sind mindestens drei bis fünf Entwickler nötig, plus die Kapazität, diese Stellen dauerhaft zu besetzen und zu halten. In Zeiten des IT-Fachkräftemangels ist das für viele mittelständische Unternehmen eine echte Herausforderung.

Einen einzelnen Entwickler neben seinem Tagesgeschäft etwas bauen lassen: Das ist der deutlich häufigere Fall. Die Anfangsinvestition ist gering, die versteckten Kosten zeigen sich erst später: Abhängigkeit von einer einzelnen Person, fehlende Qualitätssicherung, langsame Umsetzung, und im schlimmsten Fall eine Software, die nach dem Weggang des Entwicklers nicht mehr wartbar ist.

Warum Einzelentwickler-Projekte scheitern

Das Problem ist nicht mangelnde Kompetenz des Entwicklers, sondern strukturell.

Kein Sparring: Gute Software entsteht im Austausch. Architekturentscheidungen, die ungeprüft getroffen werden, haben eine hohe Fehlerquote. In einem Team werden Annahmen hinterfragt, Alternativen diskutiert und blinde Flecken aufgedeckt. Ein Einzelner hat diese Korrektivfunktion nicht.

Keine Vertretung: Wenn der Entwickler krank wird, im Urlaub ist oder das Unternehmen verlässt, steht die Entwicklung still. Bei geschäftskritischer Software ist das ein reales Risiko, das viele Unternehmen erst ernst nehmen, wenn es eingetreten ist.

Geteilte Aufmerksamkeit: In den meisten Fällen ist Softwareentwicklung nicht die einzige Aufgabe. Der Entwickler betreut parallel die IT-Infrastruktur, beantwortet Support-Anfragen und pflegt bestehende Systeme. Die Fachanwendung konkurriert mit dem Tagesgeschäft um seine Zeit. Das führt zu verzögerten Lieferungen und Frustration auf beiden Seiten.

Keine etablierten Prozesse: Qualitätssicherung, automatisierte Tests, strukturiertes Deployment: All das entsteht in einem Team aus Notwendigkeit. Ein Einzelner überspringt diese Schritte, weil der Aufwand unverhältnismäßig erscheint. Das funktioniert kurzfristig, rächt sich aber langfristig in Form von Fehlern, Instabilität und steigender Wartungskomplexität.

Die Alternative: Eigene Software, externes Team

Die Entscheidung steht nicht zwischen „alles intern“ und „alles abgeben“. Es gibt einen Mittelweg, der die Vorteile beider Ansätze kombiniert.

Das Unternehmen behält die volle Kontrolle über die Software. Es entscheidet, was gebaut wird, wie die Anforderungen aussehen und wann geliefert wird. Die Software gehört dem Unternehmen, nicht dem Dienstleister.

Die Entwicklung übernimmt ein externes Team, das genau das jeden Tag macht: professionelle Softwareentwicklung mit etablierten Prozessen, Qualitätssicherung und Vertretungsregelungen. Wenn jemand im Team ausfällt, steht nicht alles still.

Kontrolle bedeutet nicht, dass alles intern stattfinden muss. Kontrolle bedeutet, dass das Unternehmen entscheidet, was gebaut wird, und das Ergebnis besitzt. Wie die Umsetzung organisiert ist, ob intern, extern oder als Mix, ist eine operative Frage, keine strategische.

Checkliste Individualsoftware

Wann „selbst entwickeln“ trotzdem richtig ist

Es gibt Situationen, in denen ein internes Entwicklerteam die bessere Wahl ist:

Wenn Software das Kernprodukt des Unternehmens ist, nicht nur ein unterstützendes Werkzeug. Wenn das Unternehmen groß genug ist, um ein vollständiges Team dauerhaft auszulasten und zu halten. Wenn die Entwicklungsgeschwindigkeit so hoch sein muss, dass die Abstimmung mit einem externen Team zum Engpass würde.

Für die meisten mittelständischen Unternehmen, die Software zur Unterstützung ihrer Geschäftsprozesse brauchen, ist das nicht der Fall. Dort ist ein externer Partner mit einem eingespielten Team oft die wirtschaftlichere und risikoärmere Lösung.

Fazit

„Wir entwickeln das lieber selbst“ ist ein verständlicher Impuls. Aber zwischen dem Wunsch nach Kontrolle und der Realität professioneller Softwareentwicklung liegt eine Lücke, die sich nicht mit einem einzelnen Entwickler schließen lässt. Die ehrliche Frage lautet nicht „intern oder extern?“, sondern „haben wir die Struktur, um Software professionell zu entwickeln?“ Wenn die Antwort nein ist, ist ein erfahrenes externes Team die bessere Investition als ein überarbeiteter Einzelkämpfer.