Vibe Coding in HubSpot: Lücken schließen statt neu bauen

Für Rechnungen an deutsche Behördenkunden braucht es elektronische Rechnungen über staatliche Portale. HubSpot kann das nicht – zumindest noch nicht offiziell. Es gibt auch keine brauchbare Integration zwischen HubSpot und LexOffice, keine, die Jira-Zeiterfassung direkt in die Abrechnung einspeist, und keine, die deutsche Mehrwertsteuerlogik – Reverse Charge, EU versus Drittland – zuverlässig abbildet. Genau an dieser Stelle hätte man früher entweder eine Insellösung gebaut, einen Entwickler engagiert oder sich mit halbgaren Workarounds abgefunden. Ich habe mich stattdessen sechs Wochen mit Vibe Coding und Claude Code hingesetzt und danach lief die komplette Projektabrechnung unseres Unternehmens automatisiert durch HubSpot.

Das Ergebnis ist kein neues CRM und kein neues SaaS-Produkt. Es sind drei kleine, klar umrissene Module innerhalb einer bereits bestehenden, gesicherten Plattform. Und genau dieser Unterschied ist der eigentliche Punkt.

Du willst wissen, wie ich dabei konkret vorgegangen bin, inklusive der Stolpersteine? Die ganze Geschichte gibt's im Podcast – Hier reinhören.

Inhaltsverzeichnis:

• Was Vibe Coding eigentlich ist und was nicht
• Der eigentliche Unterschied: Lücken schließen statt Plattform ersetzen
• Fallbeispiel 1: Die Buchhaltungsstrecke
• Fallbeispiel 2: Editierbare Website-Module
• Fallbeispiel 3: Angebote als interaktive Verkaufsobjekte
• Wo die Grenze liegt
• Fazit
• FAQ

Was Vibe Coding eigentlich ist und was nicht

Den Begriff prägte Andrej Karpathy, Mitgründer von OpenAI, im Februar 2025 in einem Tweet: Man beschreibt in natürlicher Sprache, was man will, akzeptiert den generierten Code weitgehend ungeprüft und lässt eine KI den Rest erledigen (Karpathy, 2025). Ende 2025 wählte Collins Dictionary „Vibe Coding" zum Wort des Jahres – ein Beleg dafür, wie schnell sich die Praxis in der breiten Softwareentwicklung etabliert hat.

In der öffentlichen Debatte klingt das oft nach Alles-oder-nichts: Entweder man vertraut der KI komplett und lässt sie ganze Anwendungen bauen oder man bleibt bei klassischer Entwicklung. Eine aktuelle Studie zu Entwicklerpraxis zeigt aber ein differenzierteres Bild: Vertrauen in KI-Tools entsteht in der Praxis selten pauschal, sondern schrittweise – durch wiederholtes Prüfen statt durch blinde Übernahme (Vibe coding: programming through conversation with artificial intelligence, 2025). Genau dieses Muster erlebte auch ich beim Vibe Coding: Die Anweisung, die ich Claude am häufigsten geben musste, war schlicht „Lies dir die Dokumentation nochmal in Ruhe durch." Erst mit diesem Schritt – Claude aktiv auf die offiziellen API-Dokus von HubSpot und LexOffice zu verweisen, statt Annahmen zu vertrauen – wurde das Ergebnis verlässlich.

Der eigentliche Unterschied: Lücken schließen statt Plattform ersetzen

Die naheliegende Frage lautet: Warum nicht gleich eine komplette Speziallösung bauen? Die Antwort liegt in dem, was man beim Selbstbau einer Unternehmenssoftware alles mitdenken muss und was in bestehenden Plattformen bereits gelöst ist – Hosting, Datenschutz, Zugriffsrechte, Nutzerverwaltung, Ausfallsicherheit, Backups, gleichzeitige Bearbeitung durch mehrere Personen. Ein CRM oder ERP komplett neu zu vibecoden bedeutet, all das selbst zu verantworten, meist ohne die Erfahrung, die für Betrieb und Absicherung einer solchen Software nötig wäre.

Diese Abwägung ist kein neues Phänomen – sie ist im Kern das, was die Wirtschaftsinformatik seit Jahren unter dem Begriff Shadow IT diskutiert: von Mitarbeitenden selbst gebaute oder beschaffte IT-Lösungen außerhalb der offiziellen IT-Governance, die zwar reale Bedürfnisse lösen, aber eigene Sicherheits- und Wartungsrisiken mitbringen (Haag & Eckhardt, 2017). Der entscheidende Unterschied bei den NoDitch-Modulen: Sie entstehen nicht neben HubSpot, sondern innerhalb von HubSpot – als private App auf dem eigenen Account, teilweise sogar über HubSpots eigene Serverless-Funktionen ausgeführt. Gehostet, abgesichert und datenschutzrechtlich eingebettet ist damit weiterhin die Plattform, nicht eine selbstgebaute Insellösung nebenher. Man bewegt sich innerhalb einer bereits geprüften Umgebung, statt eine neue, ungeprüfte zu schaffen.

Fallbeispiel 1: Die Buchhaltungsstrecke

Der erste Anwendungsfall war die Verbindung zwischen HubSpot, LexOffice und Jira. Das Ziel war: Aus einem gewonnenen Deal automatisch eine Auftragsbestätigung generieren, die Kundennummer zurück nach HubSpot spiegeln und am Ende die in Jira gebuchten Projektstunden direkt in die Rechnung übernehmen – ohne manuellen Export von Timesheets.

Was sofort funktionierte, war die reine Datenverbindung: Deal-Informationen nach LexOffice übertragen, Auftragsbestätigung erzeugen, Kundennummer zurückschreiben. Schwieriger wurde es bei den Rand- und Ausnahmefällen, die man erst kennt, wenn man sie einmal falsch gemacht hat: eine vom CRM abweichende Rechnungsanschrift, unterschiedliche Mehrwertsteuersätze je nach Kundenstandort, die Frage, wer im Unternehmen überhaupt berechtigt sein soll, eine Rechnungsadresse zu ändern. Bezeichnend ist dabei eine explizite Vorgabe an das Modell: keine Fallback-Werte setzen, wenn eine Information nicht eindeutig ist. Lieber ein Fehler, der auffällt, als eine stillschweigend falsche Zahl in der Buchhaltung.

Ein Nebeneffekt, mit dem niemand gerechnet hatte: Damit die Automatisierung funktioniert, musste der Produktkatalog in HubSpot deutlich sauberer und die Angebote deutlich standardisierter werden als vorher. Was zunächst nach zusätzlichem Aufwand aussah, wurde im Rückblick zur Verbesserung – weniger individuell zusammengeschriebene Angebote, dafür wiederverwendbare, klar kalkulierbare Bausteine.

Das Ergebnis: Die App wickelt inzwischen die komplette Projektabrechnung unseres Unternehmens ab – sowohl alle Retainer-Verträge mit festen Monatsbeträgen als auch sämtliche Time-and-Material-Verträge auf Stundenbasis. Theoretisch ließen sich heute alle laufenden Projekte per Knopfdruck gleichzeitig abrechnen.

Fallbeispiel 2: Editierbare Website-Module 

Der zweite Bereich betraf die Unternehmenswebsite, die ebenfalls auf HubSpot läuft. Der naheliegende Ansatz wäre gewesen, eine komplette Seite per Prompt generieren zu lassen. Genau davon wurde bewusst abgesehen – aus einem sehr konkreten Wartbarkeitsproblem: Wer eine komplette Seite bei jeder Änderung neu promptet, riskiert bei jedem einzelnen Wunsch, dass an anderer Stelle etwas kaputtgeht, das vorher funktioniert hat. Zwei Stunden Zeitaufwand für einen an sich einfachen Gantt-Chart, bei dem ständig woanders etwas verrutschte, waren der praktische Beleg dafür.

Der bessere Weg war, einzelne HubSpot-Module zu bauen, die zwar mit Claude Code entwickelt, aber danach über normale Freitextfelder direkt im Editor bearbeitbar sind – Texte ändern, Buttons ergänzen, Schriftarten anpassen, ohne erneut zu prompten. Und wenn eine neue Version eines Moduls ausprobiert werden soll, bleibt die alte einfach bestehen, bis die neue sich bewährt hat. Kein Neubau der ganzen Seite, sondern gezielte, rückbaubare Einzeländerungen.

Das Ergebnis: Die Module funktionieren zuverlässig, bis hin zu einer durchscrollbaren Animation, die optisch durch ein neuronales Netz führt. Live ist die neue Website damit aber noch nicht – der eigentliche Relaunch steht noch bevor.

Fallbeispiel 3: Angebote als interaktive Verkaufsobjekte

Der dritte und aktuellste Fall nutzt eine erst wenige Wochen alte Beta-Funktion im HubSpot Commerce Hub: Auch Angebote lassen sich inzwischen aus denselben Drag-and-Drop-Modulen bauen wie Webseiten. Damit wurde aus einem reinen Preis-Dokument etwas, das eher wie eine kleine, durchscrollbare Website wirkt – mit Case Studies, die direkt aus den CRM-Datensätzen der Referenzkunden gezogen werden, mit Team-Mitgliedern samt Foto und Kontaktdaten aus den HubSpot-Kontakten, und mit einem Gantt-Chart, der sich automatisch aus den Leistungszeiträumen der Angebotspositionen erzeugt.

Vorher lag diese Art von Kontext – Projektpläne, erste Analysen, Zusammenarbeit-Skizzen – häufig in einer separaten Confluence-Seite als Begleitdokument. Jetzt gehört sie zum Angebot selbst. Was vorher Vertragsbestandteil war und was nur Begleitmaterial, war dadurch mitunter unscharf; jetzt ist beides an einem Ort.

Das Ergebnis: Ein erstes Angebot in diesem neuen Format ist bereits im Einsatz; ein Beispiel ist bereits online auf LinkedIn.

Wo die Grenze liegt

Wie viel Zeit ein KI-gestütztes Modell bei klar umrissenen Programmieraufgaben tatsächlich spart, ist inzwischen auch außerhalb von HubSpot recherchiert: In einem kontrollierten Experiment mit professionellen Entwicklerinnen und Entwicklern führte der Einsatz eines KI-Assistenten zu einer um 55,8 Prozent schnelleren Bearbeitung einer definierten Programmieraufgabe (Peng et al., 2023). Für kleine, klar abgegrenzte Aufgaben – genau wie die HubSpot-Module – deckt sich das mit der praktischen Erfahrung.

Für ein komplettes CRM oder ERP gilt das ausdrücklich nicht. Wer im Alleingang, ohne Entwicklungserfahrung, eine komplexe Business-Software allein mit einer KI bauen will, unterschätzt in der Regel genau die Dinge, die im Hintergrund unsichtbar bleiben, bis sie ausfallen: Backups, Skalierung, Zugriffskontrollen, das Verhalten bei gleichzeitiger Bearbeitung durch mehrere Personen. Die realistische Einordnung lautet deshalb: Vibe Coding eignet sich hervorragend, um innerhalb einer bestehenden, bereits abgesicherten Plattform gezielt die Lücken zu schließen, die es dort nicht gibt – nicht dafür, die Plattform selbst zu ersetzen.

Fazit

Der eigentliche Wert liegt nicht darin, dass jetzt jedes Unternehmen sein eigenes CRM bauen kann. Er liegt darin, dass die vielen kleinen, oft sehr spezifischen Lücken zwischen Plattform und Realität – deutsche Buchhaltungslogik, branchenspezifische Sonderfälle, fehlende Integrationen für kleine Nischen – plötzlich ohne externen Entwicklungsauftrag lösbar sind. Für Unternehmen, die HubSpot oder Atlassian-Produkte bereits im Einsatz haben, bedeutet das: Bevor man eine weitere Insellösung kauft oder ein Team monatelang wartet, lohnt sich der Blick, ob sich die Lücke nicht direkt in der eigenen Plattform schließen lässt.

Wer mehr über die Details, Reverse Charge, abweichende Rechnungsadressen, Fallback-Werte in der Buchhaltung, hören will: Im Podcast erzähle ich, wo es hakte und wo nicht – Hier reinhören.