Der Churros-Irrtum: Warum Kundenintegrationen ein gutes SaaS zerstören können

Jeder B2B-SaaS-Gründer kennt diesen Moment.

Ein neuer Kunde unterschreibt. Er mag das Produkt. Dann sagt er den stillen Teil laut:

“Das gefällt uns. Jetzt integriert es mit unserem CRM, ERP und Lagerverwaltungssystem. Sonst wird die Beschaffung den Deal nicht genehmigen.”

In diesem Moment hört das Produkt auf, nur Software zu sein. Es wird zur Infrastruktur für das Geschäft eines anderen.

Die meisten Gründer stellen sich das wie eine Churros-Maschine vor. Teig auf der einen Seite rein, Kurbel drehen, endlose identische Churros fallen auf der anderen Seite raus. Eine Integration, dann noch eine, dann noch eine. Gleiches Muster, gleiche Form. Leicht zu skalieren.

Dieses Bild ist schön. Es ist auch gefährlich.

Kundenintegrationen sind keine Nachspeise. Sie sind Komplexität. Und Komplexität ist die Steuer, die sich still und leise summiert, bis sie das Unternehmen auffrisst.

Das Geschäft, das Sie zu führen glauben, vs. das Geschäft, das Sie tatsächlich führen

Auf dem Papier verkauft das Unternehmen ein SaaS-Produkt.

In Wirklichkeit führt das Unternehmen zwei überlappende Geschäfte, sobald der erste Enterprise-Kunde nach Integration mit internen Systemen fragt:

1. Das Produktgeschäft Features entwickeln, UX verbessern, in neue Segmente expandieren.

2. Das Integrationsgeschäft Ihre Plattform mit Dutzenden einzigartiger Unternehmensumgebungen verbinden, jede mit unterschiedlichen CRMs, ERPs, Datenmodellen, Sicherheitsregeln und Change-Control-Prozessen.

Eine Zeit lang können diese beiden Welten durch guten Willen und Heldentaten koexistieren. Ein Senior-Entwickler verdrahtet “schnell” die erste Integration. Dann schließt der Vertrieb weitere Kunden ab, die alle “dasselbe” mit “kleinen Anpassungen” wollen.

Die Zahlen wachsen still und leise:

• Jeder Kunde braucht eine Handvoll Synchronisationen: Produkte, Lagerbestand, Bestellungen, Events.
• Jede Synchronisation braucht einen Workflow, etwas Mapping, etwas Authentifizierung, etwas Monitoring.
• Jede Änderung in Ihrem Produkt oder in deren Stack muss sich in diese Flows fortpflanzen.

Das Churros-Bild lebt weiterhin in der Board-Präsentation. Die Realität ist ein wachsendes Geflecht unsichtbarer Verpflichtungen.

Zwei Arten von Komplexität, die für CEOs wichtig sind

Das klassische Paper “Out of the Tar Pit” beschreibt zwei Hauptarten von Komplexität: essentielle und akzidentelle. (curtclifton.net)

In Vorstandssprache erklärt:

• Essentielle Komplexität Das ist die Komplexität der realen Welt. Ihr Kunde hat regionale Preisregeln, Ausnahmen für Schlüsselkunden, Legacy-Lagerregeln, unterschiedliche Steuerbehandlungen und Multi-Brand-Kataloge. Um sich mit dieser Realität zu integrieren, muss das System sie verstehen. Diese Komplexität lässt sich nicht wegwünschen.

• Akzidentelle Komplexität Das ist das Chaos, das aus Tools, Architektur und Prozessen entsteht. Halb dokumentierte APIs. Zufällige Skripte, die niemand anfassen will. Flows, die nur ein Freelancer versteht. Logs, die niemand lesen kann. All das ist optionaler Schmerz. Er entsteht aus Entscheidungen.

Für einen Gründer gibt es eine dritte Ebene, die noch wichtiger ist:

• Existentielle Komplexität Das passiert, wenn essentielle und akzidentelle Komplexität sich verbinden, bis sie die Existenz des Unternehmens bedrohen. Budgets explodieren. Deadlines rutschen um Quartale. Onboarding stockt. Churn schleicht sich ein. Neue Investoren stellen harte Fragen und hören weiche Antworten.

Die meisten nicht-technischen Entscheider unterschätzen alle drei.

Extrem komplexe Systeme werden oft als Phantasie behandelt. Als ob jedes Integrationsproblem “mit einem Low-Code-Tool” gelöst werden könnte, oder “durch das neue AI-Plugin”, oder “durch diese Integrationsagentur”, die Magie auf einer Folie versprochen hat.

Das Muster ist vorhersehbar:

1. Komplexität wird falsch bewertet.
2. Das Team macht Zusagen, als wären Integrationen Churros.
3. Die Realität zeigt sich.
4. Geld verdampft.

Eine reale Risikogeschichte: Wenn zu frühes Skalieren das Unternehmen tötet

Betrachten Sie ein Venture-backed-Unternehmen in den Vereinigten Staaten, das an Hardware- plus Softwarelösungen für Lebensmittel-Lieferung nach Hause arbeitete.

• Das Produkt funktionierte in einigen Pilot-Städten.
• Eine kleine Gruppe von Partnern war zufrieden.
• Der Vorstand wollte Wachstum. Schnell.

Das Management behandelte Integrationen mit neuen Partnern und Lagerhäusern als gelöstes Problem. Die interne Logik sah so aus:

“Wir haben bereits mit Partner A und Stadt A integriert. Der Rollout auf Partner B und Städte B, C, D ist dasselbe, nur mehr davon.”

Außer es war nicht so.

• Jeder neue Partner hatte leicht unterschiedliche operative Regeln.
• Jede Stadt hatte unterschiedliche Logistik-Einschränkungen und Carrier-Verträge.
• Jede neue Integration multiplizierte Edge-Cases in der Software und in den Geräten.

Das Unternehmen versuchte, die ganze Maschine auf einmal zu skalieren. Integrationen hinkten hinter Vertriebszielen her. Ops-Teams improvisierten Workarounds. Bug-Fixing und Feuerwehr-Einsätze fraßen die Roadmap.

Das Endergebnis war brutal:

• Zu viel Investorengeld verbrannt an unfertigen Integrationen.
• Keine stabile Basis begeisterter Referenzkunden.
• Ein Produkt, das vielversprechend aussah, aber ein Geschäft, das die Komplexität nicht tragen konnte.

Das Unternehmen schloss.

Die Lektion ist einfach und unbequem. System-Komplexität ist keine abstrakte “Engineering-Sache”. Sie ist eine existentielle Geschäftsvariable.

Der Low-Code-Traum: Boxen, Pfeile und ein falsches Sicherheitsgefühl

In den letzten Jahren versprachen Low-Code-Plattformen wie Make und Zapier, Integrationen zu demokratisieren. Blöcke ziehen. Felder mappen. Auf Speichern klicken. Automationen laufen in der Cloud. (Zapier)

Sie haben absolut echten Wert:

• Schneller Proof of Concept.
• Günstige Experimente.
• Einmalige interne Automationen.

Make zum Beispiel lässt Teams “Szenarien” von Modulen entwerfen und exportiert sie dann als JSON-Blueprints, die woanders importiert werden können. (BENOCODE) Zapier bietet jetzt einen visuellen Editor, um komplexe Workflows auf einen Blick zu sehen. (Zapier)

Für einen oder zwei Kunden ist das in Ordnung. Ein technisch versierter Account Manager kann in einer Woche einen funktionierenden Flow zusammenbauen. Umsatz zeigt sich. Alle sind glücklich.

Das Problem beginnt, wenn dieser Ansatz zur Integrationsstrategie für Dutzende von Kunden wird.

Die versteckten Risiken:

1. UI-Drift Leute tweaken Flows direkt im Web-Interface, um Vorfälle zu beheben. Diese Live-Edits kehren nie zur Dokumentation oder Versionskontrolle zurück. Mit der Zeit weiß niemand wirklich, was in Produktion läuft. (Make Help Center)

2. Schwache Lifecycle-Kontrolle Blueprints können exportiert und importiert werden, aber der Prozess, eine JSON-Datei in ein vollständig aktives, korrekt geplantes, gesichertes Szenario zu verwandeln, braucht immer noch benutzerdefinierte Skripte und Disziplinen. Teile dieses Lifecycle leben innerhalb der Plattform, Teile in Ad-hoc-Code. (BrowserAct)

3. Eingeschränktes lokales Testen Diese Tools sind gebaut, um in der Vendor-Cloud zu laufen. Sie können nicht exakt dasselbe Szenario auf einem Entwickler-Laptop hochfahren, es Schritt für Schritt laufen lassen und einen Debugger anhängen. Das verlangsamt die Diagnose und fördert “Trial in Production”. (Zapier)

4. Opake Performance- und Fehlermodi Wenn ein Szenario langsamer wird oder still stirbt, kann die Ursache ein falsch konfigurierter Header, ein geändertes API-Limit, ein kaputtes Mapping oder ein versteckter Timeout sein. Teams reagieren am Ende auf Tickets, anstatt Risiken proaktiv zu managen. (LowCode Agency)

“Boxen klicken” in einem Low-Code-Interface funktioniert, solange die Anzahl der Flows klein bleibt und die Stakes niedrig sind. Sobald Kundenintegrationen kritische Revenue-Plumbing werden, verwandelt sich derselbe Ansatz in akzidentelle Komplexität im großen Maßstab.

Der Camel-Weg: Integrationen als Infrastruktur, nicht als Bastelprojekt

Auf der anderen Seite des Spektrums steht das Apache-Camel-Ökosystem, und insbesondere Camel K. Camel ist ein ausgereiftes Integrationsframework. Camel K ist seine Cloud-native-Variante, die direkt auf Kubernetes läuft und einen Kubernetes-Operator verwendet, um Integrationen zu bauen und zu deployen. (Red Hat Docs)

Schlüsselideen in einfachen Worten:

• Jede Integrationsroute ist deklariert in Dateien: Java, YAML oder andere unterstützte Formen.
• Wiederverwendbare Bausteine namens Kamelets leben als einzelne YAML-Definitionen. Jedes Kamelet beschreibt, wie man sich mit einem System als Quelle oder Senke verbindet. (Apache Camel)
• Ein dedizierter Operator überwacht den Cluster, nimmt diese Routen und Kamelets auf, baut Container und führt sie aus. (Red Hat Docs)

In menschlicher Sprache:

Statt “Flow als Zeichnung in einem Vendor-Account” bekommt das Unternehmen “Flow als Spezifikation in versionskontrollierten Dateien”. Statt durch ein Webformular zu klicken, committen Engineers eine Änderung in Git und lassen den Operator Build und Rollout übernehmen.

Es gibt mehr gute Nachrichten:

• Local- und Dev-Modus Camel K unterstützt ein Dev-Mode-Flag, das Engineers schnell iterieren lässt, während es immer noch dieselbe Art von Artefakten generiert, die in Produktion verwendet werden. Lokale Operator-Setups sind für Entwicklung und Debugging dokumentiert. (Apache Camel)

• GitOps-freundlich Weil alles deklarativ ist, passt es zu GitOps-Praktiken, wo Git die Source of Truth ist und Kubernetes den gewünschten Zustand anwendet.

• Gleiches Modell für jeden Kunden Ein Routen-Deskriptor kann für viele Kunden parametrisiert werden. Secrets und kundenspezifische Einstellungen leben in Kubernetes-Config und Secrets, nicht in zufälligen UI-Screens. (Apache Camel)

Das lässt Komplexität nicht verschwinden. Es verändert ihre Form.

• Essentielle Komplexität bleibt: Kunden haben immer noch chaotische Geschäftsregeln.
• Akzidentelle Komplexität wird reduziert: weniger unsichtbare Klicks, mehr explizite Contracts.
• Existentielle Komplexität wird gemanagt: Integrationen sehen mehr wie Infrastruktur aus und weniger wie improvisierte Kunst.

Low Code vs. Camel: Welche Risiken sind Sie wirklich bereit zu tragen

Aus CEO-Perspektive ist die Frage nicht “Low Code oder High Code”. Die echte Frage ist:

“Wo wollen wir, dass Komplexität lebt, und wer wird dafür bezahlen, wenn es schiefgeht?”

Ein einfacher Vergleich.

Low-Code-Plattform für Kundenintegrationen

Vorteile

• Schnelle Demos und Piloten.
• Freundlich für Nicht-Engineers.
• Gut für interne Automationen und einfache Partner-Setups.

Risiken

• Governance lebt in Menschen und Prozessen, nicht in der Plattform selbst.
• Versionskontrolle, Testing und Promotion-Workflows müssen custom um das Tool herum gebaut werden.
• Vendor-Lock-in genau an dem Punkt, wo das Unternehmen sich mit Kunden verbindet.
• Schwieriger, in Verträgen Versprechen über Recovery-Zeiten und Change-Windows zu machen.

Camel mit Kubernetes-Operator und deklarativen Routen

Vorteile

• Integrationen ausgedrückt als Code oder YAML in Git.
• Stärkere Passung mit Security-, Audit- und Change-Management-Erwartungen.
• Local- und Dev-Mode-Support für ernsthafte Diagnose und sichere Evolution.
• Einfacher, Echtzeit-Integrationen mit Batch-Jobs, Queues und anderer Cloud-Infrastruktur zu mischen. (Red Hat Docs)

Risiken

• Braucht ein kleines aber echtes Plattform-Team.
• Vorab-Investition in Tooling und Prozess.
• Weniger visuell freundlich für nicht-technisches Personal.

Die Wahl ist keine Modefrage. Es geht darum, wo das Unternehmen sein begrenztes Komplexitäts-Budget ausgeben will.

Wie Unterschätzung von Komplexität zu Budget- und Deadline-Schäden wird

Wenn Gründer und CEOs Integrationen wie Churros behandeln, zeigen sich drei vorhersehbare Ausfälle.

1. Budget-Überläufe, die wie “Pech” aussehen Schätzungen basieren auf dem ersten einfachen Fall. Essentielle Komplexität späterer Kunden ist nicht eingepreist. Akzidentelle Komplexität aus Tools und Shortcuts ist nicht sichtbar. Wochen werden zu Monaten. Kosten driften nach oben. Der Vorstand hört, dass “APIs komplizierter waren als erwartet”.

2. Deadlines, die nicht zweimal hintereinander eingehalten werden können Integrationen rutschen, Onboarding verlangsamt sich, kommerzielle Teams verlieren Glaubwürdigkeit. Der Vertrieb kompensiert, indem er überverkauft, was zukünftige Integrationen tun werden. Jede Verzögerung multipliziert politische Kosten in Kundenorganisationen.

3. Strategische Optionen, die still verschwinden Der Eintritt in eine neue Branche, das Onboarding eines großen Anker-Kunden oder die Expansion in eine neue Region wird riskant, weil die Integrations-Baseline fragil ist. Ein Unternehmen kann “produkt-ready” und “go-to-market-ready” sein, aber nicht “integrations-ready”.

Im Extremfall, wie das Lebensmittel-Lieferbeispiel zeigt, tötet Komplexität das Geschäft, nicht weil die Idee falsch war, sondern weil die Integrations-Engine nicht mithalten konnte.

Ein praktisches Mitigations-Playbook für nicht-technische Leader

Technische Teams können über Frameworks debattieren. Leadership braucht eine Checkliste.

Hier ist ein pragmatisches Playbook.

1. Benennen Sie die Integrationen als Produktlinie

Auf der Roadmap und in Board-Diskussionen behandeln Sie “Kundenintegrationen” als distinkte Produktlinie mit:

• Eigentümern
• Budget
• Roadmap
• Qualitätsschwellen

Wenn Integrationen als “Misc-Tasks” innerhalb von Engineering leben, werden sie immer gegen glänzende Features verlieren.

2. Bitten Sie Ihr Team, essentielle von akzidenteller Komplexität zu trennen

Einfache Fragen erzwingen Klarheit:

• Welche Teile unserer Integrationen sind inhärent zu Kunden-Geschäftsregeln und Vorschriften.
• Welche Teile sind selbst zugefügt wegen Tool-Wahl, Shortcuts oder fehlender Automatisierung.

Referenzpunkte wie “Out of the Tar Pit” können helfen, interne Diskussionen in einer geteilten Sprache geerdet zu halten: essentiell vs. akzidentell. (curtclifton.net)

Das Ziel ist nicht, CEOs zu Engineers zu machen. Das Ziel ist, Komplexität sichtbar und verhandelbar zu machen.

3. Entscheiden Sie explizit, wo das Unternehmen auf dem Spektrum sitzt

Auf einer Seite: hauptsächlich Low Code plus ein paar Skripte. Auf der anderen Seite: Code und Camel-Style-Routen gemanagt von einem Operator.

Die Entscheidung sollte passen zu:

• Ticket-Volumen und Vertrags-Commitments.
• Talent bereits im Team.
• Regulierungs- und Security-Anforderungen in den Zielmärkten.

Implizite Entscheidungen sind normalerweise teurer als explizite.

4. Verlangen Sie grundlegende Guardrails, bevor neue Integrationen starten

Unabhängig von der Technologie sollten Teams mindestens haben:

• Eine einzige Source of Truth für jeden Integrations-Flow in einem Repository.
• Einen definierten Weg, um eine Änderung zu deployen und zurückzurollen.
• Monitoring, das zwei einfache Fragen schnell beantworten kann: “Läuft es” und “Was ist beim letzten Mal kaputtgegangen”.
• Eine klare Policy, die Ad-hoc-Edits in Produktions-Tools ohne Follow-up in Konfiguration und Code verbietet.

Wenn das Unternehmen Camel und Kubernetes verwendet, verlangen Sie eine schriftliche Beschreibung, wie Dev-Mode, Operator-Rollout und Configuration-Management in der Praxis funktionieren. (Apache Camel) Wenn das Unternehmen Low-Code-Tools verwendet, verlangen Sie eine schriftliche Beschreibung, wie Blueprints, Imports, Environment-Separation und Vendor-Lock-in gehandhabt werden. (Make Help Center)

5. Passen Sie Wachstum an Integrations-Reife an

Bevor Sie eine Welle neuer Logos versprechen, prüfen Sie, ob die Integrations-Engine sie glaubwürdig unterstützen kann.

Ein gesundes Muster:

• Begrenzen Sie bewusst neue komplexe Integrationen, bis es eine stabile Pipeline gibt.
• Verwandeln Sie ein paar Leuchtturm-Kunden in Integrations-Erfolgsgeschichten.
• Erst dann rampen Sie Vertriebs-Versprechen hoch.

Es ist besser, das Unternehmen zu sein, das eine kleinere Gruppe von Kunden sehr glücklich macht, als das Unternehmen, das viele unterschreibt und sie in ihren Kern-Operationen im Stich lässt.

Abschließender Gedanke: Respektieren Sie die Teergrube

Die Kern-Botschaft von “Out of the Tar Pit” ist einfach: Komplexität ist der Hauptfeind in großen Systemen. Sie wächst still und widersteht Heldentaten. (kmdouglass.github.io)

Für B2B-SaaS-Unternehmen, die von Kundenintegrationen abhängen, ist diese Komplexität nicht abstrakt. Sie ist finanziell, operativ und existentiell.

Gründer und CEOs müssen nicht zu Architekten werden. Sie müssen:

• Aufhören, sich Integrationen als Churros vorzustellen.
• Essentielle Komplexität in der Kunden-Realität anerkennen.
• Akzidentelle Komplexität in Tools und Prozessen aggressiv reduzieren.
• Existentielle Komplexität als erstklassiges Geschäftsrisiko behandeln, gleichauf mit Wettbewerb, Regulierung und Finanzierung.

Die Unternehmen, die das früh tun, bauen Integrations-Engines, die sich zu ihrem Vorteil entwickeln. Die Unternehmen, die das nicht tun, entdecken schließlich, dass das echte Produkt nie nur die App auf dem Bildschirm war. Das echte Produkt war das Versprechen, dass “das in Ihrem chaotischen, realen Geschäft funktionieren wird”.

Dieses Versprechen ist zu wichtig, um es dem Zufall und hübschen Diagrammen zu überlassen.