CRM-Eigenbau mit Vibe-Coding: Eine gute Idee?

Das verlockende LinkedIn-Versprechen – Vibe Coding statt SaaS-Lizenz?

In den letzten Monaten begegnet mir auf LinkedIn immer wieder dasselbe Versprechen: Mit KI-gestütztem Vibe Coding könne man teure SaaS-Lösungen wie CRM oder ERP einfach selbst nachbauen und so die laufenden Lizenzkosten radikal senken. Die Posts klingen überzeugend, sammeln Likes und sprechen einen wunden Punkt an.

Und ich verstehe den Reiz. SaaS-Lizenzen sind ein erheblicher Kostenblock, der mit jedem Nutzer und jeder Funktion wächst. KI-Coding-Tools wirken gleichzeitig mächtig und zugänglich. Da liegt der Gedanke nahe: „Warum nicht selbst bauen, wenn die Technologie es heute hergibt?" Das klingt rational und unternehmerisch.

Genau hier möchte ich ansetzen, ohne den Zeigefinger zu heben. Denn die eigentliche Frage lautet nicht, ob sich Code generieren lässt. Das funktioniert heute beeindruckend gut. Die Frage ist, ob das Ergebnis Enterprise-tauglich ist: sicher, skalierbar, wartbar und compliant. In diesem Artikel zeichne ich aus Beobachtung und Erfahrung ein realistisches Gegenbild zu den Versprechen aus dem Feed.

Was Vibe Coding wirklich ist – und was es kann

Zunächst eine nüchterne Einordnung: Vibe Coding bezeichnet KI-gestützte Softwareentwicklung, bei der man Code generiert, ohne jeden technischen Aspekt selbst vollständig zu beherrschen. Man beschreibt in natürlicher Sprache, was man möchte, und die KI liefert eine funktionierende Lösung. Für schnelle Prototypen ist das ein legitimer und produktiver Ansatz [10].

Wichtig ist mir eine klare Differenzierung nach Unternehmensgröße. Für ein kleines Unternehmen mit einfachen, eng abgegrenzten Anforderungen kann Vibe Coding für den produktiven Einsatz durchaus sinnvoll sein. Ein internes Tool, eine schlanke Übersicht, eine spezifische Automatisierung: Hier kann KI echten Mehrwert schaffen, ohne dass gleich ein ganzes System auf dem Spiel steht.

Dieser Artikel richtet sich nicht gegen KI in der Softwareentwicklung. Das Gegenteil ist der Fall. Der Wandel des Berufsbilds vom reinen Coden hin zum Orchestrieren von KI-Agenten ist real, und Domänenwissen sowie strategischer Überblick werden wichtiger als reine Codiergeschwindigkeit [10]. Mir geht es um eine sehr konkrete Anwendung: den Einsatz von Vibe Coding zum Eigenbau komplexer Enterprise-Software wie CRM oder ERP im Mittelstand und in größeren Organisationen. Genau dort verschiebt sich die Rechnung fundamental, weil die Anforderungen an Sicherheit, Architektur und Betrieb in einer anderen Liga spielen.

Das Eisberg-Problem: Was ein CRM oder ERP wirklich ist

Moderner Computermonitor zeigt ein übersichtliches CRM-Dashboard mit Diagrammen und Kontaktlisten.

Die sichtbare Oberfläche eines CRM ist nur ein kleiner Teil des Gesamtsystems.

Was man sieht: Frontend und Business-Logik

Wenn man ein CRM oder ERP von außen betrachtet, sieht man Eingabemasken, Listen, Dashboards und einige Geschäftsregeln. KI wird sogar zunehmend zur primären Benutzeroberfläche solcher Systeme: Anwender sprechen das System in natürlicher Sprache an, statt durch Masken und Menüs zu navigieren [2]. Diese sichtbare Schicht lässt sich mit KI-Tools heute tatsächlich erstaunlich schnell erzeugen. Genau das nähren die LinkedIn-Versprechen.

Doch das ist nur die Spitze des Eisbergs. Die sichtbare Oberfläche ist der kleinste Teil dessen, was ein professionelles System ausmacht.

Was darunter liegt: Infrastruktur, Skalierbarkeit, Sicherheit, Compliance

Unter der Wasserlinie liegt die eigentliche Arbeit: Infrastruktur, Skalierbarkeit, Sicherheitsarchitektur, Datenkonsistenz, Integrationen in bestehende Systeme, Zugriffsmanagement, Audit-Trails und Compliance. Diese Schichten entscheiden darüber, ob ein System im Alltag trägt oder zur Belastung wird.

Dazu kommt die Sicherheit als Fundament jeder Kundenbeziehung. Das Vertrauen der Kunden steht und fällt mit der Sicherheit eines Unternehmens [8]. Wer ein CRM oder ERP selbst betreibt, übernimmt diese Verantwortung vollständig.

Etablierte SaaS-Anbieter haben Jahre gebraucht, um diese Schichten aufzubauen, und überwachen sie kontinuierlich mit spezialisierten Teams. Diese Tiefe ist mit KI-generiertem Code allein nicht replizierbar, denn die eigentliche Komplexität liegt nicht im Code, sondern in tausenden gelernten Entscheidungen und in der Betriebserfahrung über viele Jahre.

Vibe Coding braucht Skill – auch wenn es so nicht aussieht

Entwickler prüft kritisch KI-generierten Code auf versteckte Fehler und strukturelle Schwächen.

KI-generierter Code kann aufgeräumt wirken – und dennoch fundamentale Schwächen verbergen.

Das Kontrollproblem: Wer den Code nicht versteht, kann ihn nicht beurteilen

Hier liegt mein zweites Kernargument: Wer nicht versteht, was der generierte Code tatsächlich tut, hat keine Kontrolle über das eigene System. Moritz Breit, Leiter des Entwicklungsteams bei CentralStationCRM, bringt es treffend auf den Punkt. Für ihn ist KI in der Entwicklung wie ein Junior Developer: „Ich kann dem nicht einfach irgendwas geben und erwarten, dass da gute Qualität herauskommt" [3]. Und weiter: „Die KI taugt aktuell aus meiner Sicht nur für Sachen, die ich auch selbst machen könnte. Ich erkenne dann Quatsch, weil ich eben genau weiß, worum es geht" [3].

Genau das ist der Knackpunkt. Wer die Sicherheit, Performance und Architektur eines generierten Systems nicht beurteilen kann, dem fallen Probleme erst im laufenden Betrieb auf, dann aber mit hohem Schadenpotenzial. Der Mensch als kontrollierende Instanz, der „Human-in-the-Loop", bleibt unverzichtbar [10]. Wer tiefer verstehen möchte, wo KI-Agenten im CRM wirklich helfen und wo sie an Grenzen stoßen, findet dazu eine fundierte Einschätzung im Artikel KI-Agenten im CRM: Stärken, Grenzen & Erfolgsfaktoren.

Technische Schulden: unsichtbar entstanden, teuer beseitigt

Damit komme ich zu einem Begriff, der für Entscheider zentral ist: technische Schulden. Man kann sie sich vorstellen als heute eingesparte Sorgfalt, die morgen mit Zinsen zurückgezahlt wird. Sie entstehen unsichtbar und schnell, wenn Code zwar funktioniert, aber nicht wartbar, skalierbar oder sicher ist.

Genau dieses Muster zeigt sich bei KI-gestützter Entwicklung besonders deutlich. KI-Tools ignorieren häufig die Projektarchitektur, brechen Layer-Grenzen und erzeugen technische Schulden, obwohl der Code sauber kompiliert [6]. Die Werkzeuge vergessen zudem ab einem gewissen Umfang Kontextinformationen aus früheren Phasen desselben Projekts [6]. Das Tückische daran: KI-generierter Code kann auf den ersten Blick aufgeräumt und vollständig wirken und trotzdem fundamentale Schwächen enthalten. Diese Illusion von sauberem Code ist gefährlich, weil sie ein falsches Gefühl von Sicherheit erzeugt. Und der größte Aufwand entsteht nicht beim ersten Release, sondern danach, wenn Updates, neue Anforderungen und Sicherheitsfragen auf echte Nutzung treffen [9].

Die versteckten Kosten des ERP- und CRM-Eigenbaus

Einmalige Entwicklung vs. laufender Betrieb

Die scheinbare Ersparnis verdient eine ehrliche Gegenrechnung. Die einmalige Entwicklung ist nur der Anfang. Der eigentliche Aufwand kommt mit dem Betrieb: Wartung, neue Anforderungen und Sicherheitsupdates [9]. Diese Last ist erheblich: In großen Unternehmen fließen mehr als 70 Prozent der IT-Ausgaben in Wartung und Pflege bestehender Systeme [9]. Wer selbst baut, baut diese Verpflichtung von Tag eins an mit auf.

Hinzu kommt das Sicherheitsthema. KI-generierter Code weist Analysen zufolge rund 1,7-mal mehr Sicherheitslücken auf als manuell geschriebener Code [9]. Bei einem System, das sämtliche Kundendaten enthält, ist das kein akademisches Risiko.

Abhängigkeiten und Risiken

Zur Kostenfrage gehört auch die Skalierbarkeit. Was für zehn Nutzer funktioniert, kann bei mehreren Hundert zusammenbrechen. Der nachträgliche Umbau ist dann oft teurer als die eingesparte Lizenz.

Drei weitere Risiken kommen hinzu:

Abhängigkeit von einzelnen Personen oder KI-Tools: Wenn der eine Entwickler das Unternehmen verlässt oder das KI-Tool sein Verhalten ändert oder von einem Tag auf den anderen nicht mehr verfügbar ist (Stichwort Fable/Mythos), verliert man den Überblick über das eigene System.
Kompetenzaufbau, der mit der Nutzung nicht Schritt hält [9]: Über die Hälfte der Unternehmen nennt fehlendes technisches Know-how und fehlende personelle Ressourcen als zentrale Hürde [9].
Compliance: Datenschutz, DSGVO und der AI Act erfordern dauerhafte Investitionen, und 93 Prozent der betroffenen Unternehmen erwarten hohen Aufwand allein durch den AI Act [9].

SaaS-Anbieter tragen diese Last für viele Kunden gemeinsam. Im Eigenbau trägt man sie allein, ohne dieselbe Expertise. Was zunächst günstig wirkt, wird so langfristig oft deutlich teurer als die eingesparten Lizenzkosten.

Wann Eigenbau trotzdem sinnvoll sein kann

Mir ist eine faire Differenzierung wichtig, denn nicht jedes Unternehmen ist gleich. Kleine Unternehmen mit sehr spezifischen, klar abgegrenzten Anforderungen können durchaus von Eigenentwicklungen mit KI profitieren. Wenn die folgenden Voraussetzungen zutreffen, kann ein schlankes Eigensystem die bessere Wahl sein als eine überdimensionierte Standardlösung:

Die Nutzerzahl ist überschaubar
Es wird kein hochsensibler Datenbestand verarbeitet
Kein starker Compliance-Druck herrscht
Internes technisches Know-how ist vorhanden
Das Anforderungsprofil bleibt klar umrissen

Bezeichnend ist, dass selbst ein CRM-Anbieter für kleinere Unternehmen empfiehlt, das CRM nicht isoliert zu betreiben, sondern in ein Ökosystem mehrerer Tools einzubinden, damit KI auf möglichst viele Quellen zugreifen kann [3]. Eigenbau heißt also nicht automatisch Alleingang.

Anders sieht es im Mittelstand und in größeren Unternehmen aus. Hier treffen gewachsene Prozesse, regulierte Daten, viele Nutzer und zahlreiche Integrationsanforderungen aufeinander. Genau diese Kombination macht den Eigenbau zum Risiko, weil jede einzelne Schicht professionell beherrscht werden müsste. Diese Unterscheidung ist mir ein echtes Anliegen: Es geht nicht um pauschale KI-Kritik, sondern um eine nüchterne Einschätzung, die der jeweiligen Realität gerecht wird.

Alternativen: Was stattdessen funktioniert

Wer auf den Eigenbau verzichtet, steht keineswegs ohne Optionen da. Grob lassen sich drei Kategorien unterscheiden:

Etablierte CRM- und ERP-Anbieter, die ausgereifte Sicherheits- und Skalierungsarchitekturen mitbringen.
Open-Source-Lösungen als interessante Mittelposition.
Kleinere, spezialisierte Anbieter, die einzelne Branchen oder Anwendungsfälle besonders gut abdecken.

Open Source verdient dabei besondere Beachtung. Es bietet mehr Kontrolle als klassisches SaaS, etwa über Hosting und Datenhoheit, und gleichzeitig deutlich weniger Aufwand als ein kompletter Eigenbau. Datenhoheit ist real ein wichtiges Kriterium, denn heikle Daten müssen teils On-Premise verbleiben, statt nach außen zu gelangen [10]. Allerdings setzt auch dieser Weg technisches Know-how voraus.

Wer eine ähnliche Diskussion aus dem Bereich der Fachabteilungs-Eigenentwicklung kennt, findet einen verwandten Blickwinkel im Artikel Low-Code/No-Code: Befreiungsschlag für die Fachabteilung oder Schatten-IT? – dort geht es ebenfalls um das Spannungsfeld zwischen Autonomie und Kontrollverlust.

Bei der Auswahl helfen ehrliche Evaluierungskriterien: Skalierbarkeit, Integrierbarkeit, Compliance-Unterstützung, Qualität des Supports und die Total Cost of Ownership über mehrere Jahre. Es gibt kein universelles Richtig oder Falsch. Aber es gibt nachvollziehbare Kriterien, nach denen sich eine tragfähige Entscheidung treffen lässt, statt sich von einem Versprechen leiten zu lassen.

Fazit: Die richtige Frage stellen

Am Ende läuft alles auf die richtige Frage hinaus. Sie lautet nicht „Können wir das selbst bauen?", denn die Antwort darauf ist heute oft ein technisches Ja. Die entscheidende Frage ist: „Was ist der echte Nutzen, und welche Lösung erfüllt ihn sicher und nachhaltig?" Das verschiebt den Blick weg von der Machbarkeit hin zur Verantwortung für den Betrieb.

Meine Handlungsempfehlung ist deshalb pragmatisch: Vor jedem Eigenbau-Projekt, egal ob mit KI oder ohne, gehört eine ehrliche Kosten-Risiko-Analyse auf den Tisch. Sie muss über die reine Entwicklung hinausgehen und Betrieb, Wartung, Skalierung, Sicherheit und Compliance einbeziehen. Erst dann lässt sich die vermeintliche Ersparnis seriös bewerten. Hilfreich ist auch der Blick auf die Datenbasis: KI entfaltet ihren Nutzen erst, wenn sie auf klaren Prozessen, verlässlichen Daten und sinnvoll definierten Zielen aufsetzt [4]. Intelligenz ohne Vertrauen in die Daten ist wertlos [2].

Damit schließt sich der Kreis zu den LinkedIn-Posts aus dem Einstieg. Sie klingen so überzeugend, weil sie den sichtbaren Teil des Eisbergs zeigen, die schnell generierte Oberfläche. Über Erfolg oder Misserfolg entscheidet jedoch der unsichtbare Teil darunter: die Architektur, die Sicherheit, die Skalierbarkeit und der Betrieb über Jahre. Es gibt sogar einprägsame Warnungen aus der Praxis, wenn ein KI-Agent eigenständig handelt und ohne finale Zustimmung Entscheidungen trifft [6]. Genau diese Eigendynamik gilt es zu beherrschen.

Mein Anliegen ist kein Tech-Bashing. Ich verstehe die Verlockung gut und sehe das Potenzial von KI in der Entwicklung. Aber wer die Komplexität von CRM und ERP wirklich kennt, trifft am Ende bessere Entscheidungen, unabhängig davon, wie zugänglich und mächtig die KI-Tools im Moment wirken. Diese Klarheit ist der eigentliche Wettbewerbsvorteil.

Häufige Fragen

Was ist Vibe Coding und warum ist es für Enterprise-Systeme problematisch? Vibe Coding bezeichnet KI-gestützte Softwareentwicklung, bei der Code ohne vollständiges technisches Verständnis generiert wird. Für einfache Tools funktioniert das gut. Bei komplexen Enterprise-Systemen wie CRM oder ERP fehlen jedoch die tieferen Schichten: Sicherheitsarchitektur, Skalierbarkeit, Compliance und laufender Betrieb – diese entstehen nicht automatisch durch KI-generierten Code.

Was sind technische Schulden und wie entstehen sie beim Vibe Coding? Technische Schulden sind heute eingesparte Sorgfalt, die morgen mit Zinsen zurückgezahlt wird. KI-Tools ignorieren häufig die Projektarchitektur und brechen Layer-Grenzen – der Code kompiliert sauber, enthält aber strukturelle Schwächen. Diese werden erst sichtbar, wenn das System unter Realbedingungen wächst oder aktualisiert werden muss.

Wann kann ein CRM-Eigenbau mit KI-Unterstützung sinnvoll sein? Für kleine Unternehmen mit klar abgegrenzten Anforderungen, überschaubarer Nutzerzahl, geringem Compliance-Druck und vorhandenem internem Know-how kann ein schlankes Eigensystem durchaus sinnvoll sein. Im Mittelstand und in größeren Organisationen überwiegen jedoch die Risiken durch Komplexität, Regulierung und Skalierungsanforderungen deutlich.

Welche Alternativen gibt es zum CRM-Eigenbau? Die drei wichtigsten Alternativen sind: etablierte CRM- und ERP-Anbieter mit ausgereifter Infrastruktur, Open-Source-Lösungen als Kompromiss zwischen Flexibilität und Sicherheit sowie kleinere spezialisierte Anbieter für spezifische Branchen oder Anwendungsfälle. Entscheidend ist eine ehrliche Bewertung nach Skalierbarkeit, Compliance-Unterstützung und Total Cost of Ownership.