Die meisten Teams treffen diese Entscheidung falsch herum. Sie wählen n8n, weil Prototypen schnell entstehen, bringen etwas zum Laufen, das ein paar Monate funktioniert — und verbringen dann sechs Monate damit, Funktionen nachzurüsten, für die die Plattform nie konzipiert war. Oder sie springen direkt zu Custom-Code für einen Workflow, den n8n problemlos abgedeckt hätte — und zahlen dreimal so viel ohne messbaren Mehrwert.
Die Frage ist nicht, welche Option abstrakt besser ist. Sie ist, welche zu Ihrem tatsächlichen Workload-Profil passt. Dieser Artikel liefert Ihnen einen konkreten Entscheidungstest: fünf Fragen, die vorhersagen, ob ein n8n-Agent in 18 Monaten noch seinen Dienst tut — oder ob Sie auf eine Migration zusteuern.
Was n8n wirklich ist (und was nicht)
n8n ist eine Workflow-Automatisierungsplattform mit einem visuellen Node-Editor, einer umfangreichen Bibliothek vorgefertigter Integrationen und vertretbarer Unterstützung für LLM-basiertes Routing, einfache Tool-Nutzung und RAG-ähnliches Retrieval. Es ist self-hostable — ein echter Vorteil für europäische Unternehmen mit Anforderungen an die Datenhaltung.
Für die richtigen Probleme liefert es: SaaS-Anwendungen verbinden, Webhook-Payloads routen, geplante Anreicherungsjobs ausführen, interne Benachrichtigungsflüsse aufbauen. Einen KI-Schritt oben auf diese Flows zu legen ist oft genau so einfach, wie es in der Demo aussieht.
Die Grenze zeigt sich, wenn der Agent über mehrere Schritte hinweg schlussfolgern, komplexe Zustände halten, bei Tool-Fehlern sauber einspringen oder Audit-Trails durchsetzen muss, die ein Compliance-Team prüfen wird. An diesem Punkt schreibt man Custom-JavaScript in n8n-Nodes — was im Wesentlichen Custom-Entwicklung mit schlechterem Tooling und ohne integrierte Versionskontrolle im Free-Tier bedeutet (Git-Source-Control erfordert einen Business- oder Enterprise-Plan ab €667/Monat+).
Einen umfassenderen Blick auf die Kompromisse von n8n im Produktivbetrieb bietet n8n KI-Agenten: Die ehrlichen Pro und Contra für Unternehmen.
Fünf Fragen, die die richtige Wahl vorhersagen
1. Wie viele Verzweigungen muss Ihr Agent gleichzeitig bearbeiten?
Der visuelle Graph von n8n ist leistungsstark für lineare oder leicht verzweigte Flows. Wenn Ihr Agent eine Kundenanfrage bearbeiten muss, indem er gleichzeitig Ihr CRM abfragt, den Lagerbestand prüft, die jüngste Bestellhistorie abruft und entscheidet, ob eskaliert werden soll — und das alles abhängig vom Account-Typ —, wächst der Graph auf eine Weise, die schwer zu verstehen und noch schwerer zu warten ist.
Bei der Custom-Entwicklung von Agenten lässt sich diese bedingte Logik im Code ausdrücken, wo sie hingehört: testbar, reviewbar und nicht abhängig von einer Canvas, die niemand außerhalb des Automatisierungsteams lesen kann.
n8n ist geeignet: bis zu drei oder vier Verzweigungspfade, überwiegend lineare Logik.
Custom ist geeignet: komplexe Entscheidungsbäume, parallele Tool-Aufrufe oder Logik, die sich häufig ändert.
2. Verarbeitet der Agent sensible Daten — Patientenakten, Finanzdaten, HR-Informationen?
Self-hosted n8n hält Daten auf Ihrer Infrastruktur, was ein echter Vorteil gegenüber cloud-gehosteten Alternativen ist. Dennoch operieren Sie innerhalb des Ausführungsmodells von n8n, seiner Credential-Speicherpatterns und der Standard-Logging-Einstellungen. Feldverschlüsselung, Custom-Audit-Logging oder rollenbasierte Zugriffskontrolle auf Agent-Funktionen erfordern es, um die Plattform herum zu arbeiten — nicht mit ihr.
Custom-Entwicklung gibt Ihnen eine saubere Architektur, in der jede Datenverarbeitungsentscheidung explizit und nachvollziehbar ist. Für Schweizer Unternehmen, die unter dem revDSG operieren, oder für EU-Kunden unter der DSGVO hat diese Explizitheit echten Compliance-Wert. Mehr dazu unter KI-Agenten und DSGVO: Automatisierung, die Sie vertreten können.
n8n ist geeignet: interne Prozessautomatisierung mit nicht-sensiblen Daten oder Teams, die das Sicherheitsmodell von n8n bereits mit ihrem DSB validiert haben.
Custom ist geeignet: regulierte Daten, strenge Audit-Anforderungen oder Multi-Tenant-Deployments, bei denen Datenisolation nicht verhandelbar ist.
3. Was passiert, wenn der Agent im großen Maßstab einen Fehler macht?
Jeder Agent versagt irgendwann. Die Frage ist, ob der Fehler ein kleines Ärgernis oder ein ernstes Vorkommnis ist.
In n8n ist die Fehlerbehandlung auf Node-Level-Retries und Fehlerzweige ausgerichtet. Das funktioniert für einfache Integrationen. Bei Agenten, die mit Kunden interagieren, Datensätze in Ihrem ERP ändern, Kommunikation versenden oder Finanztransaktionen auslösen, brauchen Sie mehr: strukturiertes Fallback-Verhalten, Human-in-the-Loop-Checkpoints, Rollback-Logik und operative Beobachtbarkeit, die Ihnen zeigt, nicht nur dass etwas fehlgeschlagen ist, sondern warum — und welche Eingaben es verursacht haben.
Custom-Entwicklung ermöglicht es Ihnen, genau die Fehlerbehandlung aufzubauen, die Ihr Risikoprofil verlangt — und nichts weniger.
n8n ist geeignet: interne Automatisierung, bei der eine fehlgeschlagene Ausführung nur bedeutet, dass jemand den Task manuell wiederholt.
Custom ist geeignet: kundengerichtete Agenten, Agenten die in System-of-Record schreiben, oder jeder Workflow, bei dem ein stiller Fehler reale Konsequenzen hat.
4. Soll dieser Agent Ihr Produkt oder Ihre Dienstleistung differenzieren?
Wenn Sie einen Back-Office-Prozess automatisieren, den jedes Unternehmen in Ihrer Branche ungefähr gleich handhabt, machen die vorgefertigten Integrationen von n8n und die vergleichsweise niedrigen Build-Kosten Sinn. Sie konkurrieren nicht darüber, wie Sie Spesenberichte verarbeiten.
Wenn der Agent eine kundengerichtete Funktion ist — ein gebrandetes Support-Erlebnis, ein KI-gestützter Vertriebsassistent mit tiefem Produktkatalog-Wissen, eine Empfehlungs-Engine auf Basis Ihrer proprietären Daten — dann ist der Agent selbst Teil Ihres Wertangebots. Proprietäre Logik, Persönlichkeit und fein abgestimmtes Verhalten leben nicht komfortabel in einem visuellen Workflow-Editor.
n8n ist geeignet: Commodity-Automatisierung, bei der Differenzierung keine Rolle spielt.
Custom ist geeignet: jeder Agent, der Teil Ihres Wettbewerbsvorteils ist — oder den Sie als Feature an Ihre eigenen Kunden verkaufen möchten.
5. Wie schnell ändern sich Ihre Anforderungen?
n8n lässt sich für einfache Änderungen schnell aufbauen und anpassen. Aber wenn Flows wachsen, werden visuelle Graphen genuinen schwer zu refaktorieren. Eine neue Integration zu einer 40-Node-Canvas hinzuzufügen ist nicht dieselbe Operation wie bei einer 5-Node-Canvas. Und wenn Ihre Anforderungen sich rasch weiterentwickeln — neue LLM-Modelle, neue Integrationen, sich ändernde Business-Logik — wollen Sie eine Codebase mit Unit-Tests und einer ordentlichen Deployment-Pipeline, keine Canvas, die Sie nicht anzufassen wagen.
n8n ist geeignet: stabile, gut verstandene Prozesse, bei denen sich Anforderungen selten ändern.
Custom ist geeignet: Umgebungen, in denen Sie schnell iterieren, neue Modelle bei Verbesserungen übernehmen oder Ihre Agent-Architektur Produktänderungen absorbieren soll, ohne alles neu aufzubauen.
Die Kostenfrage (ehrlich betrachtet)
Die niedrigeren initialen Build-Kosten von n8n sind real. Ein Workflow, der in n8n vielleicht zwei Wochen braucht, kann bei Custom-Entwicklung mehrere Wochen oder länger dauern — der Unterschied ist reell, auch wenn die genauen Zeitrahmen je nach Team und Komplexität variieren. Für unkomplizierte Anwendungsfälle ist dieser Kostenunterschied die richtige Entscheidung.
Wo sich die Rechnung verschiebt, ist beim Gesamtkosten über 18 bis 24 Monate. Wenn n8n-Flows Custom-Code-Nodes, undokumentierte Workarounds und durch Credential-Hacks zusammengehaltene Integrationen ansammeln, steigt die Wartungslast steil an. Teams unterschätzen auch häufig, wie viel Zeit Operations-Mitarbeiter damit verbringen, fehlgeschlagene Ausführungen in komplexen n8n-Deployments zu überwachen und neu zu starten.
Betrachten Sie ein illustratives Szenario: Ein Logistikunternehmen mit 30 Mitarbeitern baut einen Kundenbenachrichtigungs-Agenten in n8n. Anfangskosten: niedrig, vier Wochen Aufwand eines Contractors. Achtzehn Monate später verarbeitet der Agent dreimal das Volumen, hat sechs Custom-JavaScript-Nodes, die niemand vollständig versteht, und bricht jedes Mal, wenn sich eine vorgelagerte API ändert. Die Migration zu Custom-Code endet teurer als der ursprüngliche Build gewesen wäre. Dieses Muster wiederholt sich — nicht weil n8n schlechte Software ist, sondern weil die Plattform in Woche eins richtig und in Monat achtzehn falsch war.
Für eine genauere Analyse, wie sich diese Kosten akkumulieren, siehe Die wahren Kosten von KI-Agenten: Custom vs. Platform TCO.
Eine schnelle Entscheidungstabelle
| Signal | Spricht für n8n | Spricht für Custom |
|---|---|---|
| Team hat keine dedizierten Entwickler | Ja | — |
| Agent interagiert mit regulierten Daten | — | Ja |
| Anforderungen sind stabil und klar definiert | Ja | — |
| Agent ist kundengerichtet oder differenzierend | — | Ja |
| Budget ist begrenzt und Use Case ist einfach | Ja | — |
| Volumen wird innerhalb von 12 Monaten erheblich wachsen | — | Ja |
| Fehlerbehandlungsanforderungen sind komplex | — | Ja |
| Prozess ist ein Commodity-Back-Office-Flow | Ja | — |
Kein einzelnes Signal ist ausschlaggebend. Wenn Sie für einen geschäftskritischen Workflow drei oder mehr Punkte in der Custom-Spalte erzielen, sind die initialen Build-Kosten fast sicher gerechtfertigt.
Der hybride Weg, der wirklich funktioniert
Für viele Unternehmen ist die richtige Antwort sequenziell statt binär. Bauen Sie einen funktionierenden Prototypen in n8n — er beweist das Konzept, legt die echten Integrationsanforderungen frei und erlaubt Business-Stakeholdern, schnell Mehrwert zu sehen. Migrieren Sie dann die Produktionsversion zu Custom-Code, sobald die Anforderungen stabil und der Business Case validiert sind.
Das vermeidet Overengineering, bevor die Anforderungen klar sind, sperrt Sie aber nicht in eine Plattformarchitektur ein, die nicht wachsen kann. Es ist auch einfacher, die Custom-Entwicklungsinvestition zu rechtfertigen, sobald ein live n8n-Agent den Geschäftswert demonstriert.
Unter Den Agent über die Plattform hinaus entwickeln: der Migrationspfad zu Custom erfahren Sie, wie diese Migration typischerweise abläuft und was sie kostet.
Und wenn Sie noch entscheiden, ob Sie den Agenten überhaupt selbst bauen oder beauftragen sollen, behandelt Build vs. Buy: ein Entscheidungsrahmen für KI-Agenten die übergeordnete Make-vs-Buy-Frage.
Wo Orange ITS ins Spiel kommt
Wir entwickeln Custom KI-Agenten für Schweizer und europäische Unternehmen — und helfen Kunden auch herauszufinden, wann sie keinen brauchen. Wenn Ihr Workflow wirklich zu n8n passt, sagen wir Ihnen das. Wenn Sie bereits etwas in n8n aufgebaut haben und langsam an seine Grenzen stoßen, können wir einschätzen, was eine Migration bedeuten würde und ob sie angesichts Ihres aktuellen Setups sinnvoll ist.
Die fünf obigen Fragen sind dieselben, die wir in einem ersten Gespräch durchgehen. Wenn Sie sie auf Ihre spezifische Situation mit jemandem anwenden möchten, der diese Einschätzung dutzende Male vorgenommen hat, buchen Sie ein 30-minütiges Gespräch mit unserem Team. Kein Pitch, keine Präsentation — nur eine direkte Antwort darauf, ob Ihr Use Case n8n, Custom-Entwicklung oder etwas dazwischen erfordert.