In den letzten zwanzig Jahren haben die meisten Unternehmen Softwareprobleme geloest, indem sie SaaS gekauft haben.
Das war meist sinnvoll. Custom Software war teuer, langsam und riskant. Wenn ein Workflow nicht strategisch wichtig genug fuer ein eigenes Projekt war, war die praktische Antwort: das Produkt kaufen, das am besten passt, und das Unternehmen daran anpassen.
So entstand das SaaS-Modell, das wir alle kennen. Ein Produkt bedient tausende Unternehmen. Jeder Kunde bekommt ungefaehr dieselbe Oberflaeche, dasselbe Datenmodell, dieselbe Workflow-Logik und dieselbe Meinung darueber, wie die Arbeit erledigt werden sollte. Es gibt vielleicht Custom Fields, Integrationen, Einstellungen und ein paar Personalisierungsoptionen. Aber der Grunddeal ist einfach: Ihr Unternehmen nutzt dasselbe Produkt wie alle anderen.
Dieser Tradeoff ergab Sinn, solange Softwareproduktion der teure Teil war.
LLMs veraendern diesen Tradeoff.
Es ist heute viel leichter, Software fuer ein Unternehmen, ein Team oder einen sehr spezifischen Workflow zu bauen. Ein nuetzliches internes Tool braucht kein Venture-finanziertes Produktteam dahinter. Es braucht keine oeffentliche Roadmap, keinen Marketplace-Eintrag und keine Pricing Page. Es muss nur das Problem innerhalb des Unternehmens loesen, das es nutzen wird.
Das oeffnet eine echte Chance fuer kleine und mittlere Unternehmen.
Das alte Custom-Software-Modell war zu schwer
Custom Software bedeutete frueher ein grosses Projekt, bevor die erste nuetzliche Version sichtbar wurde.
Es gab Scoping, Design, Engineering, Infrastruktur, Testing, Rollout, Support und die dauerhafte Frage, wer das Ganze warten wuerde. Fuer viele Unternehmen war die Antwort einfach: nicht bauen, solange es keine Alternative gibt.
SaaS gewann, weil es einen grossen Teil dieser Last entfernte. Man zahlte ein Abo, akzeptierte die Annahmen des Produkts und kam voran. Selbst wenn die Passung nicht perfekt war, war das meist besser als ein eigenes System von Grund auf zu bezahlen.
Viele interne Workflows leben deshalb heute in Tools, die fast passen.
Das CRM passt fast zum Sales-Prozess. Das Projekt-Tool passt fast zum Delivery-Modell. Die Finanzvorlage passt fast zur Kalkulationslogik. Das Reporting-Dashboard beantwortet fast die eigentliche Managementfrage. Das Team lernt die Luecken, baut Workarounds und behandelt die Reibung als normal.
LLMs machen diese Normalitaet weniger akzeptabel.
Wenn ein Team jetzt viel schneller ein schmales Tool bauen kann, veraendert sich die Frage. Sie lautet nicht mehr nur: “Koennen wir uns Custom Software leisten?” Sie lautet: “Ist dieser Workflow spezifisch genug, dass Custom Software besser waere als der naechste Kompromiss?” Das verwandte Buy-versus-Build-Risiko haben wir in Should We All Now Build Our Own Internal Tools with AI? beschrieben.
Vibe Coding wird viele nuetzliche Tools erzeugen
Es ist nichts falsch daran, wenn Menschen kleine Tools fuer sich selbst bauen.
Vibe Coding ist nuetzlich. Ein Gruender kann ein kleines Dashboard bauen. Eine Operations-Verantwortliche kann einen Dokumentenhelfer erstellen. Eine Finance-Person kann einen Pricing Calculator prototypisieren. Ein Sales-Team kann einen schnellen Account-Research-Workflow bauen. Die Schwelle, aus wiederkehrender Reibung ein funktionierendes Tool zu machen, ist stark gesunken.
Unternehmen sollten experimentieren. Menschen, die die Arbeit verstehen, wissen oft sehr genau, wo die Reibung liegt. Wenn sie selbst eine erste Version bauen koennen, koennen sie testen, ob die Idee nuetzlich ist, bevor daraus ein groesseres Projekt wird.
Das Problem beginnt, wenn der Workflow nicht mehr einfach ist.
Ein Prototyp, der einer Person bei einer Aufgabe hilft, ist etwas anderes als ein System, das echte Unternehmensdaten verarbeitet, Business Logic traegt, Freigaben unterstuetzt, Outputs erzeugt, auf die andere sich verlassen, oder nachgelagerte Prozesse antreibt. Ab diesem Punkt geht es nicht mehr nur darum, “eine App zu bauen”. Es wird Produktdesign, Datenmodellierung, Software Engineering, Security, Operations und Change Management.
Dort werden viele vibe-gecodete interne Tools gegen eine Wand laufen. Es ist dasselbe Urteilsproblem wie in Everybody is a developer now. What happens next? : Software-Artefakte werden leichter zu erzeugen, aber Architektur, Security, UX, Daten und operative Kontrolle zaehlen weiterhin.
Komplexe Workflows brauchen weiterhin professionelle Struktur
Die wertvollsten internen Tools sind selten einfache Formulare mit einer schoenen Oberflaeche.
Oft geht es um Datenpipelines, unordentliche Inputs, menschliche Reviews, mehrstufige Prozesse, Ausnahmen, Berechtigungen, Berechnungen und nachgelagerte Aktionen. Das Tool muss vielleicht Daten aus mehreren Systemen bereinigen, Datensaetze klassifizieren, Analysen fahren, Kalkulationen unterstuetzen, Dokumente erzeugen, ein CRM aktualisieren oder Entscheidungen fuer eine Fuehrungskraft vorbereiten.
Diese Arbeit ist nicht einfach, nur weil ein LLM Code schreiben kann.
Die schwierige Frage ist, was das System bedeuten soll.
Welche Datenquelle ist verbindlich? Welche Felder zaehlen? Was passiert, wenn ein Wert fehlt? Welche Schritte koennen automatisiert werden? Wo braucht es menschliche Freigabe? Wie soll das Tool sein Ergebnis erklaeren? Was muss geloggt werden? Was passiert, wenn sich eine API aendert? Wer besitzt den Workflow nach dem Launch?
Diese Fragen sind keine Implementierungsdetails. Sie sind das Produkt.
Ein Team kann sich durch die erste sichtbare Schicht vibe-coden und trotzdem bei den haerteren Teilen feststecken. Die Oberflaeche existiert, aber das Datenmodell ist schwach. Die Demo funktioniert, aber die Edge Cases brechen. Die Berechnung sieht richtig aus, aber niemand weiss, wie sie auditiert wird. Der erste Nutzer mag das Tool, aber das zweite Team kann es ohne Aenderungen nicht nutzen. Das Tool kommt nah genug heran, um spannend zu sein, und wird dann zu fragil, um ihm zu vertrauen.
Das ist die Wand. Der Weg darum herum sieht meistens eher aus wie AI Workflows und Closed-Loop-Systeme : strukturierte Inputs, reviewbare Aenderungen, Tests, Logs und kontrollierte Feedback-Loops um die Arbeit.
Der Sweet Spot ist professionelle Custom Software mit LLMs
Es gibt einen Mittelweg zwischen alter Custom Software und ungesteuerten internen Experimenten.
LLMs fuer Geschwindigkeit nutzen, aber das Tool professionell designen und bauen lassen. Hier wird AI Consulting and Implementation nuetzlicher als reine Beratung.
Das bedeutet: Ein Team kommt hinein, versteht den Workflow, mappt die Daten, identifiziert die Entscheidungspunkte und baut Software um die konkrete Arbeitsweise des Unternehmens herum. Das Tool muss keine Marktkategorie bedienen. Es muss nicht jeden moeglichen Kaeufer zufriedenstellen. Es muss nur zu diesem Unternehmen, diesem Prozess, diesen Daten und dieser Nutzergruppe passen.
Das ist ein viel leichteres Ziel als generisches SaaS. Generisches SaaS muss viele Kunden, Edge Cases, Integrationsmuster, Berechtigungsmodelle, Onboarding-Pfade und widerspruechliche Meinungen darueber unterstuetzen, wie die Arbeit erledigt werden soll. Interne Custom Software kann fokussierter sein. Die Nutzer sind bekannt. Der Workflow ist bekannt. Die Business Rules koennen explizit sein. Die erste Version kann klein, nuetzlich und um echten operativen Kontext gebaut sein.
LLMs machen diesen Ansatz fuer mehr Unternehmen wirtschaftlich realistisch.
Sie senken Implementierungskosten, beschleunigen Iteration und machen es leichter, vom Verstehen des Workflows zu einem funktionierenden Tool zu kommen. Aber sie ersetzen kein Urteil. Der Wert entsteht aus der Kombination von LLM-gestuetzter Entwicklungsgeschwindigkeit mit Produkt- und Engineering-Disziplin.
Ist das der Anfang der SaaSpocalypse?
Fuer manche SaaS-Unternehmen: ja.
Low-Value-SaaS ist verwundbar. Wenn ein Produkt vor allem ein duenner Workflow Wrapper, ein generisches Dashboard oder ein etwas sperriges Prozess-Tool ist, werden Kunden immer haeufiger fragen, ob eine interne Custom-Version besser passen wuerde.
Aber SaaS verschwindet nicht.
Starke SaaS-Produkte haben weiterhin Vorteile. Sie bedienen grosse Zielgruppen mit geteilten Beduerfnissen. Sie uebernehmen regulatorische, Security-, Infrastruktur-, Support- und Wartungsarbeit. Sie profitieren von Netzwerkeffekten, Integrationen und Produktreife. Wenn ein SaaS-Tool genau tut, was eine grosse Zielgruppe will, bleibt es nuetzlich.
Der Druck ist groesser, wenn SaaS den Workflow zu stark besitzt. Das ist das Problem, das wir in Agentisches Entsiloing: Arbeit aus SaaS-Silos holen beschrieben haben: Unternehmen brauchen mehr Kontrolle ueber Daten, Regeln und operatives Gedaechtnis, auf die Agents und interne Tools angewiesen sind.
Die groessere Veraenderung ist eine neue Kategorie.
Kleine und mittlere Unternehmen koennen jetzt interne Tools beauftragen, die frueher zu teuer gewesen waeren. Diese Tools sitzen zwischen SaaS und traditioneller Individualsoftware. Sie sind custom, aber nicht ueberladen. Sie sind schnell zu bauen, aber nicht beliebig. Sie sind spezifisch, aber professionell designt und gewartet.
Das ist ein Blick darauf, wohin Software geht.
Mehr Tools werden fuer spezifische Menschen, spezifische Teams, spezifische Partnergruppen und spezifische Unternehmen gebaut werden. One-size-fits-all Software wird weiter existieren, aber sie wird fuer viele Unternehmensworkflows nicht mehr die einzige realistische Option sein.
Um das Unternehmen bauen, nicht um die Kategorie
Die wichtige Frage ist nicht, ob ein Unternehmen alles selbst bauen sollte.
Das sollte es nicht.
Die Frage ist, wo die Arbeit spezifisch genug, wertvoll genug und unpassend genug fuer Standardsoftware ist, dass ein Custom Tool ein besseres Operating Model schafft als der naechste SaaS-Kompromiss.
Gute Kandidaten haben oft ein paar Gemeinsamkeiten:
- der Workflow wiederholt sich oft
- das aktuelle Tool passt schlecht
- der Prozess haengt von unternehmensspezifischem Wissen ab
- die Daten kommen aus mehreren Quellen
- der Output treibt echte Entscheidungen oder nachgelagerte Arbeit
- das Team hat bereits manuelle Workarounds
- der Wert einer besseren Passung ist leicht zu erklaeren
Das sind die Workflows, in denen interne Custom Software Hebel schafft.
Bei XYZ interessiert uns genau diese Arbeit. Wir arbeiten bereits an aktiven Faellen, in denen LLM-gestuetzte Entwicklung schnelles Vorankommen moeglich macht, waehrend Daten, Workflow und Support-Modell ernst genommen werden.
Wenn Ihr Unternehmen einen spezifischen internen Workflow hat, der nie ganz in Standardsoftware passt, melden Sie sich oder buchen Sie ein Meeting . Wir helfen Ihnen herauszufinden, ob ein Custom Tool sinnvoll ist, was die erste Version tun sollte und wie man es baut, ohne aus einer guten Idee ungestuetzte interne Software zu machen.