Fuer den groessten Teil der Softwaregeschichte mussten Unternehmen eine Grundentscheidung treffen.
Standardsoftware kaufen oder etwas Eigenes bauen.
In der Praxis war diese Entscheidung oft weniger offen, als sie klang.
Individuelle Software zu bauen war frueher so arbeitsintensiv, langsam und teuer, dass viele Unternehmen es kaum als echte Option betrachtet haben. Wenn ein Workflow nicht strategisch besonders wichtig, ungewoehnlich gross oder mit Standardsoftware gar nicht abbildbar war, lautete die Standardantwort meist: kaufen.
Kaufen bedeutete meist schnellere Einfuehrung, weniger Anfangsrisiko und weniger Engineering-Entscheidungen. Bauen bedeutete meist mehr Flexibilitaet, aber auch mehr Kosten, mehr Wartung und mehr Moeglichkeiten, Fehler zu machen.
KI veraendert diese Gleichung.
Es ist jetzt viel leichter fuer ein Unternehmen, schmale interne Software fuer den eigenen Gebrauch zu bauen. Ein Team kann ein Workflow-Tool, einen Angebotsassistenten, eine Reporting-Schicht, ein Meeting-Prep-Tool, eine Dokumentenpipeline oder ein leichtes Operations-Dashboard viel schneller als frueher erstellen. Diese Software braucht keine Pricing-Page, keinen Sales-Prozess, kein Customer-Success-Team und keine polierte Marktgeschichte. Sie muss nur fuer das interne Team funktionieren, das sie benutzt.
Das ist ein echter Wandel. Er senkt die Schwelle fuer individuelles internes Tooling so stark, dass Bauen keine seltene Ausnahmeentscheidung mehr ist. In manchen Teams wird es jetzt sogar zum ersten Impuls. Genau deshalb muss die alte Buy-versus-Build-Debatte neu betrachtet werden.
Aber der leichte Teil ist nicht der wichtige Teil.
Schwer bleibt zu wissen, was man bauen sollte, wie es strukturiert sein sollte, wo es andocken muss, wie viel Kontrolle es braucht und wer verantwortlich ist, wenn es anfaengt zu brechen.
KI macht individuelles Tooling billig. Sie macht es nicht gut.
Die neue Versuchung liegt auf der Hand.
Wenn ein Team an einem Tag eine brauchbare interne App generieren kann, warum sollte es das Geschaeft weiter um generische Software herum verbiegen, die nur halb passt? Warum sollte man mit unbequemen CRM-Workflows, unhandlichen Reporting-Exporten, verstreuten Meeting-Notizen oder repetitiven manuellen Uebergaben leben, wenn ein individuelles Tool die Luecke schliessen kann?
In vielen Faellen ist dieser Impuls richtig.
Es gibt genug Workflows, bei denen der Kauf einer grossen Plattform ueberzogen ist und das Warten auf eine Vendor-Roadmap wenig Sinn ergibt. Ein kleines individuelles Tool kann die richtige Antwort sein, wenn der Workflow spezifisch, wiederkehrend und eng mit der tatsaechlichen Arbeitsweise des Unternehmens verbunden ist.
Das Problem ist, dass KI Softwaregenerierung wie Softwarefertigstellung wirken laesst.
Ein Team bekommt ein funktionierendes Interface. Der Kern-Prompt verhaelt sich in der Demo gut genug. Ein paar Integrationen sind zusammengeklemmt. Das Ergebnis fuehlt sich nuetzlich an, also beginnt die Organisation stillschweigend, sich darauf zu verlassen.
Genau dort beginnen die Probleme.
Das Tool kann immer noch schwache Berechtigungen haben. Edge Cases koennen unbehandelt sein. Der Workflow kann von einer Person abhaengen, die die Prompts versteht. Logging kann duenn sein. Fehlermodi koennen unsichtbar sein. Das Datenmodell kann keinen sinnvollen Weg in Version zwei haben. Das Tool kann einen Schmerzpunkt loesen und gleichzeitig drei neue Wartungspflichten erzeugen.
Billige Produktion ist nicht dasselbe wie gutes Engineering.
Das ist dasselbe Urteilsproblem, das wir in Jetzt ist jeder Entwickler. Was passiert als Naechstes? beschrieben haben. KI senkt die Kosten fuer die Erzeugung von Softwareartefakten. Sie verbessert nicht automatisch Architektur, operative Disziplin oder Ownership.
Das eigentliche Risiko ist interner Tool-Sprawl
Die offensichtliche Sorge war frueher, dass Unternehmen zu wenig bauen, weil individuelle Software teuer war.
Die neue Sorge sollte sein, dass Unternehmen zu viel bauen, weil individuelle Software sich fast kostenlos anfuehlt.
Ein Team baut einen Lead-Routing-Helfer. Ein anderes baut einen Kunden-Zusammenfassungsassistenten. Jemand aus Operations baut eine Scheduling-Schicht. Marketing baut einen Content-Workflow. Finance experimentiert mit Rechnungsextraktion. Bald hat das Unternehmen einen wachsenden Stapel interner Tools, kleiner Automatisierungen, Prompts, Konnektoren und agentischer Workflows, den niemand als ein System betrachtet.
Jedes Tool fuer sich kann nuetzlich sein.
Zusammen koennen sie chaotisch werden.
Die Organisation endet mit halb dokumentierten Workflows, unklarer Ownership, duplizierter Logik, inkonsistenten Berechtigungen, verstreutem Datenhandling und Tools, die gerade gut genug funktionieren, um weiterzulaufen, waehrend sie still zu operativen Abhaengigkeiten werden.
Das ist die turboaufgeladene Version des alten Problems.
KI erlaubt es einem Team, viel schneller ein viel tieferes Loch zu graben. Sie kann Hebel durch internes Tooling schaffen, aber auch ein ganzes Feld halb funktionierender Software, das niemand wirklich besitzt und das niemand gern anfasst.
Das ist ein Grund, warum wir immer wieder KI-Workflows und Closed-Loop-Systeme betonen. Wenn sich internes Tooling vervielfacht, braucht es Struktur, Reviewbarkeit und kontrollierte Feedback-Loops darum herum.
Interne Tools brauchen trotzdem Produktdenken
Ein haeufiger Fehler ist, interne Software so zu behandeln, als brauche sie kein sauberes Produktdenken, weil sie “nur fuer uns” sei.
Das ist verkehrt.
Interne Software sitzt meist naeher an den eigentlichen Operations des Unternehmens als oeffentliche Software. Sie beruehrt Freigaben, Datensaetze, Dokumente, Planung, Kundenbearbeitung, Reporting und wiederkehrende Ausfuehrung. Wenn ein internes Tool verwirrend, unzuverlaessig oder schlecht berechtigt ist, landet der Schaden direkt im Unternehmen.
Dass es nicht extern verkauft wird, macht es nicht niedrigschwellig.
Gute interne Tools brauchen weiterhin:
- eine klar verantwortliche Person fuer den Workflow
- eine definierte Aufgabe
- klare Inputs und Outputs
- menschliche Freigaben, wo Risiko besteht
- sinnvolle Berechtigungen
- Verantwortung fuer Support und Wartung
- einen Plan fuer Edge Cases, Logging und Fehler
Ohne diese Grundlagen baut das Unternehmen keine Faehigkeit auf. Es baut neue operative Schulden.
Die Buy-versus-Build-Frage hat ihre Form veraendert
Die alte Version der Frage war vor allem oekonomisch.
Lohnt es sich, Engineers fuer etwas Individuelles zu bezahlen, wenn bereits ein Vendor-Produkt existiert?
Die neue Version ist staerker operativ.
Ist dieser Workflow wichtig genug, spezifisch genug und stabil genug, um interne Ownership zu rechtfertigen?
Das fuehrt zu einer nuetzlicheren Aufteilung.
Bauen, wenn der Workflow nah an Ihrem echten operativen Vorteil liegt, zu viele unbequeme Tool-Grenzen kreuzt oder eine sehr spezifische Kombination aus Automatisierung, Urteil und internem Kontext braucht.
Kaufen, wenn der Workflow Commodity-Infrastruktur ist, stark standardisiert ist oder besser von einem reifen Produkt mit etabliertem Support, Compliance und Wartung getragen wird.
Viele Unternehmen werden beides gleichzeitig tun. Sie kaufen das grosse System of Record und bauen schmale Schichten darum. Sie behalten Kernplattformen fuer CRM, Buchhaltung, Dokumente oder Support, ergaenzen aber internes KI-Tooling dort, wo das Unternehmen bessere Orchestrierung, besseren Retrieval, schnellere Drafts oder saubere operative Nachverfolgung braucht.
Dieses hybride Modell wird wahrscheinlich normal.
Der Fehler ist nicht das Bauen. Der Fehler ist das Bauen ohne Modell fuer Ownership.
Jemand muss trotzdem unterstuetzen, was gebaut wurde
Das ist vielleicht der am wenigsten glamouroese Teil der ganzen Diskussion, aber er ist der wichtigste.
Jedes interne Tool wird zum kuenftigen Problem von jemand anderem, wenn keine verantwortliche Person benannt ist.
Prompts driften. APIs aendern sich. Geschaeftsregeln entwickeln sich weiter. Teams wechseln. Datenquellen werden umbenannt. Ein Workflow, der im April offensichtlich wirkte, ergibt im Oktober keinen Sinn mehr. Ein Tool, das ein Quartal lang Zeit gespart hat, wird sechs Monate spaeter verwirrend, weil niemand die eingebauten Annahmen gepflegt hat.
Das bedeutet, dass die KI-Aera vielleicht eine haeufigere interne Rolle hervorbringt, die viele kleinere Teams bisher nicht hatten.
Nicht unbedingt eine volle Softwareabteilung. Nicht unbedingt eine klassische IT-Rolle. Sondern eher eine praktische interne Tooling-Verantwortung oder eine kleine Tooling-Funktion, die dafuer verantwortlich ist, dass die individuelle Software, Automatisierungen und der Organisation ueber Zeit brauchbar bleiben.
Grosse Unternehmen haben bereits interne Plattformteams, Workflow-Teams und Tooling-Spezialisten. Kleinere Unternehmen brauchen moeglicherweise zunehmend leichtere Versionen derselben Idee.
Wenn individuelle Software billig genug wird, wird Support-Verantwortung zur eigentlichen Knappheit.
werden wichtiger, nicht unwichtiger
Hier hat KI eine seltsame Illusion erzeugt.
Weil Bauen leichter ist, nehmen manche Teams an, dass weniger Disziplin noetig ist.
Das Gegenteil ist richtig.
Wenn ein Team schnell interne Tools aufsetzen kann, braucht es staerkere Guard Rails dafuer, was gebaut wird, welche Daten beruehrt werden duerfen, welche Workflows Freigaben brauchen, wer Aenderungen shippen darf und wie Fehler sichtbar gemacht werden. Schnellere Produktion erhoeht den Wert von Governance, weil die Menge moeglicher Fehler mitwaechst.
Das verlangt keine schwere Buerokratie. Es verlangt Betriebsstandards.
Bevor ein Team zehn interne KI-Tools baut, sollte es eine Sicht auf Fragen haben wie:
- Welche Workflows lassen sich sicher automatisieren?
- Welche brauchen menschliche Freigabe?
- Welche Tools duerfen Kunden- oder Mitarbeiterdaten beruehren?
- Wo sollen Logs und Outputs liegen?
- Wer reviewt einen Workflow, bevor er zur Abhaengigkeit wird?
- Wer repariert ihn, wenn er bricht?
Genau hier koennen ein Company-Wide Agentic Workflow , engere agentische Coding-Workflows oder ein staerkeres Security-Review nuetzlicher sein als noch eine glaenzende AI-Demo. Der schwere Teil ist nicht, noch eine weitere Art zu finden, Software zu generieren. Der schwere Teil ist, ein Umfeld zu schaffen, in dem nuetzliche Tools nuetzlich bleiben.
Wohin das fuehren koennte
Die positive Version ist klar.
Kleinere Unternehmen koennen endlich individuelles internes Tooling rechtfertigen, das frueher ausser Reichweite war. Teams koennen repetitive manuelle Arbeit abbauen, bessere Entscheidungen unterstuetzen und Software schaffen, die zu ihrer tatsaechlichen Arbeitsweise passt, statt sie in generische Workflows zu zwingen.
Die negative Version ist ebenfalls klar.
Manche Unternehmen werden sich mit fragilen internen Apps, losen agentischen Workflows und schlecht betreuten Tools fuellen, die niemand besitzen will.
Die Frage ist also nicht mehr nur, ob Sie Software kaufen oder selbst bauen sollten.
Die bessere Frage ist, ob Ihr Team interne Tools mit genug Urteilskraft, Struktur und Support-Disziplin bauen kann, damit sie sich nicht in eine zweite Schicht operativen Chaos verwandeln.
KI hat individuelle interne Software dramatisch leichter produzierbar gemacht. Sie hat sie nicht selbstwartend, selbstregulierend oder selbstbegruendend gemacht.
Darum wird der naechste echte Vorteil nicht daraus entstehen, die meisten internen Tools zu bauen. Er wird daraus entstehen, die richtigen zu bauen, mit klarer Ownership, guten Kontrollen und einem Plan fuer den Support nach der ersten Demo.
Wenn Ihr Team dieses Jahr fast jedes interne Tool bauen koennte, welche sollten trotzdem gekauft werden, welche sollten gebaut werden und wer sollte die Software besitzen, die Sie fuer sich selbst schaffen?