Der vergessene Reflex
Ende der 2000er war es noch normal, dass Unternehmen ihre internen Tools selbst bauten: das Bestellsystem, das Disposystem, die Provisionsabrechnung, die interne Wissensbasis. Mit dem Aufstieg von SaaS verschwand dieser Reflex. „Warum sollten wir das selbst bauen, wenn es das fertig gibt?" wurde zur Standardantwort in jedem Architekturmeeting.
Diese Antwort war eine Zeit lang richtig. Sie ist es heute oft nicht mehr. Eine wachsende Zahl von Unternehmen baut Backoffice-Tools wieder selbst – und das nicht aus Nostalgie, sondern weil sich die Wirtschaftlichkeit komplett gedreht hat.
Was an Enterprise-SaaS nicht mehr aufgeht
Drei Probleme häufen sich, je länger ein Unternehmen Enterprise-SaaS einsetzt:
Pricing skaliert mit dem falschen Faktor. Pro-Seat-Lizenzen, Add-on-Module für jede zweite Funktion, Pro-Connector-Gebühren bei Integrationen. Was als günstige Standardlösung beginnt, kostet nach drei Jahren mit 200 Nutzern und sechs Modulen plötzlich sechsstellig pro Jahr – ohne dass das Tool merklich besser geworden wäre.
Der Funktionsumfang ist breit und flach. Enterprise-SaaS muss alle Branchen, alle Unternehmensgrößen und alle Use Cases abdecken. Das Ergebnis sind Tools mit hunderten Features, von denen die meisten irrelevant sind, und die paar Features, die wirklich gebraucht werden, sind oft zu generisch, um den eigenen Prozess wirklich abzubilden. Workarounds, Excel-Krücken und „so machen wir das eben"-Lösungen sind die Folge.
Geschwindigkeit der Anpassung sinkt. Wer im eigenen Workflow eine Änderung braucht, wartet auf das nächste Quartals-Release des Anbieters – oder bezahlt einen Berater, um die SaaS-Plattform so weit zu verbiegen, bis sie passt. Beides ist langsam, beides ist teuer, beides erzeugt Frust beim Team, das täglich mit dem Tool arbeitet.
Was technisch jetzt möglich ist
Internal Tools selbst zu bauen, war jahrelang aus drei Gründen ein Albtraum: zu teuer, zu langsam, zu wartungsintensiv. Alle drei Gründe sind weggefallen.
Bauen ist günstig geworden. Ein KI-unterstütztes Entwicklerteam baut ein internes Bestellsystem mit Genehmigungs-Workflow, Reporting und Slack-Integration in zwei bis vier Wochen. Vor fünf Jahren waren das drei bis sechs Monate. Die Kosten sind heute oft niedriger als ein Jahr Lizenzkosten der SaaS-Alternative.
Komponenten gibt es als Lego. Authentifizierung kommt von Auth0 oder Clerk, Datenbanken von Supabase oder Neon, UI-Komponenten von shadcn, Workflow-Engines von Temporal, Reporting von Metabase. Aus diesen Bausteinen lässt sich ein produktives Tool zusammensetzen, ohne dass das Team Authentifizierung, Datenmodellierung oder Reporting von Grund auf neu erfindet.
Wartung ist beherrschbar. Was als „das müsste mal jemand pflegen" anfing, ist heute oft so klein und fokussiert, dass ein einzelner Entwickler es nebenher betreut. Hinzu kommt: KI-gestützte Code-Reviews, automatisches Refactoring und Test-Generierung haben den Wartungsaufwand drastisch gesenkt.
Was sich am Wert geändert hat
Vor zehn Jahren lieferte ein Enterprise-SaaS einen Mehrwert, den ein internes Tool nicht erreichen konnte: jahrelange Produktentwicklung, eine breite Feature-Liste, Best Practices aus tausenden Implementierungen. Dieses Wertversprechen ist erodiert.
Best Practices sind heute öffentlich. Wie ein Bestellprozess sinnvoll aufgebaut ist, wie eine Pipeline-Visualisierung aussehen sollte, wie ein Approval-Workflow funktioniert – das ist alles dokumentiert, in Blogs, in Open-Source-Projekten, in den Köpfen jedes Entwicklers, der schon mal in einem mittelständischen Unternehmen war. KI verstärkt diesen Effekt: Sie zieht Best Practices in jeden Codevorschlag.
Breite Feature-Listen sind eine Belastung. Was früher als Stärke verkauft wurde – „1.200 Features out of the box" – ist heute oft die Schwäche. Mitarbeiter finden die Funktionen nicht, die sie brauchen, oder verstehen die Konzepte nicht. Internal Tools haben den Vorteil, exakt das zu enthalten, was gebraucht wird, und nichts darüber hinaus.
Eigene Prozesse müssen nicht mehr verbogen werden. Das ist der eigentliche Hebel. Ein internes Tool, das genau den eigenen Workflow abbildet, spart pro Mitarbeiter und Tag oft fünf bis fünfzehn Minuten an Klick- und Kopierarbeit. Bei 50 Mitarbeitern sind das mehrere Personentage pro Woche, die wieder in die eigentliche Arbeit zurückfließen.
Wo Internal Tools die richtige Antwort sind
Nicht jeder Bereich eignet sich. Eigene Tools spielen ihre Stärken aus, wo drei Bedingungen zusammenkommen:
Der Prozess ist unternehmensspezifisch. Wer einen Workflow hat, der sich von dem der meisten anderen Unternehmen unterscheidet – aus historischen, regulatorischen oder strategischen Gründen –, leidet besonders unter generischen SaaS-Tools. Ein internes Tool zahlt sich genau hier am stärksten aus.
Die Nutzergruppe ist klar abgrenzbar. Internal Tools funktionieren am besten für interne Teams mit klarem Anwendungsfall: Disposition, Buchhaltung, Vertriebsoperations, Personalverwaltung. Wo eine externe Zielgruppe oder hohe Nutzerzahlen ins Spiel kommen, wird das Kosten-Nutzen-Verhältnis schwieriger.
Die Integration mit dem eigenen Datenmodell ist wertvoll. Ein Tool, das nahtlos auf interne Daten zugreift, ohne Datenexport-Importerei, schlägt jedes SaaS-Tool, das nur Standard-Schnittstellen bietet. Je tiefer die Integration sein soll, desto stärker das Argument für Eigenbau.
Wo Enterprise-SaaS weiterhin gewinnt
Drei Bereiche bleiben Domäne des SaaS-Modells:
Hochregulierte Standardprozesse. Lohnabrechnung, Buchhaltung, Steuer. Hier liefert ein guter Anbieter regulatorische Konformität als Service. Das selbst zu pflegen, ist riskant und teuer.
Kollaboration mit Externen. E-Mail, Videokonferenzen, geteilte Dokumente. Hier gewinnt die Plattform, die alle nutzen, weil Netzwerkeffekte zählen. Niemand will sein eigenes Zoom betreiben.
Spezialisierte Verticals mit echter Tiefe. Hochwertige Branchensoftware – etwa für klinische Studien, Versicherungsmathematik, oder spezifische Logistiksegmente – bietet jahrzehntelang akkumuliertes Domänenwissen, das nicht in zwei Wochen nachgebaut wird.
In diesen Bereichen sind SaaS-Anbieter nicht zu schlagen. Außerhalb davon wird der Vorteil immer dünner.
Wie der Übergang in der Praxis aussieht
Unternehmen, die diesen Schritt erfolgreich gehen, folgen meist einem ähnlichen Muster:
Erst ein Schmerzpunkt, dann eine Strategie. Es beginnt selten mit dem Vorsatz, „mehr selbst zu bauen". Es beginnt damit, dass ein konkretes Tool besonders nervt, ein eigenes Replacement gebaut wird, und alle merken: Das ging schneller als gedacht und passt besser. Aus dem Einzelfall wird ein Muster, aus dem Muster eine Strategie.
Plattform-Denken statt Tool-Denken. Wer Internal Tools systematisch baut, baut sich nach drei bis fünf Tools eine eigene interne Plattform: gemeinsame Auth, gemeinsame Datenmodelle, gemeinsame UI-Bibliothek. Diese Plattform macht das nächste Tool noch günstiger und schneller.
Klare Ownership. Eigene Tools brauchen einen verantwortlichen Owner – jemanden, der nicht nur die Technik kennt, sondern auch den Prozess. Ohne Ownership werden Internal Tools zu Karteileichen.
Wir bei nh labs begleiten genau diesen Übergang in vielen Projekten. Häufig beginnt es mit dem ehrlichen Vergleich der TCO eines bestehenden SaaS-Tools mit dem geschätzten Aufwand für eine Eigenentwicklung – und die Rechnung fällt deutlich anders aus, als die meisten Beteiligten erwartet hatten.
Fazit
Internal Tools sind zurück. Nicht als Notlösung für Unternehmen, die sich Enterprise-SaaS nicht leisten können, sondern als strategische Wahl für Unternehmen, die ihre Prozesse, ihre Daten und ihre Geschwindigkeit selbst kontrollieren wollen. Enterprise-SaaS bleibt sinnvoll – aber der Default-Reflex „dafür kaufen wir was" verliert seine Berechtigung. Wer in den nächsten zwei Jahren ein paar nervige interne Werkzeuge selbst baut und feststellt, wie viel günstiger und besser das Ergebnis ist, wird die nächste Lizenzverlängerung deutlich kritischer prüfen. Genau diese Welle hat gerade begonnen.