Wir haben selbst mit n8n angefangen
Bevor embedflow existierte, haben wir eine eigene n8n-Instanz auf unserem Hetzner-Server betrieben. Die ersten Workflows waren Social-Media-getrieben: Bild-Pipelines, Video-Verarbeitung, automatisches Posting auf mehreren Kanälen. n8n war schnell aufgesetzt, die Community ist gut, und für diese Anwendungsfälle hat es funktioniert.
Dann haben wir angefangen, komplexere Dinge damit zu bauen. Die erste Version unseres KI-Agenten für FloviAi war ein n8n-Workflow. Ein eingehender Anruf triggert die Spracherkennung, das Ergebnis geht an ein LLM, die Antwort wird per Text-to-Speech zurückgespielt. Auf dem Papier sah das logisch aus.
Wo es gekippt ist
In der Praxis hat sich schnell gezeigt, dass zwischen "funktioniert im Test" und "läuft produktiv" ein großer Unterschied liegt.
Latenz. Ein Sprachassistent muss in unter zwei Sekunden antworten, sonst fühlt sich das Gespräch unnatürlich an. Das Problem ist nicht der einzelne Node-Übergang — der kostet wenige Millisekunden. Aber n8n bietet keine echte Streaming-Pipeline: kein paralleles Audio-Processing, kein Durchreichen von Binärdaten über WebSockets, keine Kontrolle über das Timing zwischen den Verarbeitungsstufen. Für Social-Media-Posts ist das egal, für Echtzeit-Telefonie nicht.
Fehlerbehandlung. Was passiert, wenn die SMS-API nicht erreichbar ist? Oder wenn zwei Kunden gleichzeitig den letzten freien Termin buchen? n8n bietet einfache Retry-Mechanismen, aber keine feingranulare Kontrolle über Backoff-Strategien, Dead Letter Queues oder Idempotenz — nicht ohne erheblichen Zusatzaufwand außerhalb des Workflows. Bei einem produktiven System mit echten Kunden reicht das nicht.
Debugging. n8n zeigt pro Node den Fehler mit Input- und Output-Daten — das ist für einfache Workflows ausreichend. Aber bei einer Pipeline, die über mehrere Services läuft, brauchen wir mehr: strukturiertes Logging mit Mandanten- und Session-Zuordnung, Metriken in Echtzeit und korrelierte Traces über die gesamte Verarbeitungskette. Das lässt sich in einer Workflow-Engine nicht abbilden.
Skalierung. Eine Standard-n8n-Instanz verarbeitet Workflows sequentiell. Queue Mode mit Redis ist möglich, bringt aber eigene Infrastrukturkomplexität mit sich — und löst die anderen Probleme nicht. Bei wenigen Standorten ist das noch kein Problem. Aber ein System, das mit wachsender Nutzung und vielen getrennten Kundenbereichen umgehen soll, braucht eine andere Architektur.
Der Hype und die Realität
Was uns am meisten überrascht hat: Wie groß die Lücke zwischen dem ist, was in YouTube-Tutorials gezeigt wird, und dem, was im Produktivbetrieb besteht. "Baue einen KI-Agenten in 10 Minuten mit n8n" klingt großartig. Aber der Agent aus dem Tutorial hat keine Fehlerbehandlung, kein Monitoring, keine Mandantentrennung und keine Lösung für den Fall, dass das LLM mal eine unbrauchbare Antwort liefert.
Wir haben das am eigenen Produkt erlebt und daraus die Konsequenz gezogen: Für produktive Systeme schreiben wir Code.
Was wir heute machen
Jeder Automatisierungs-Workflow in FloviAi ist ein eigener Service. Terminbestätigungen, Schichtplanung, Synchronisation zwischen Modulen. Jeder Service wird unabhängig deployed und überwacht. Fehlgeschlagene Verarbeitungen landen in einer separaten Warteschlange und werden automatisch wiederholt oder manuell geprüft. Monitoring zeigt in Echtzeit, was läuft und wo etwas hängt.
Das ist aufwendiger als ein n8n-Workflow. Aber es läuft stabil, skaliert mit der Plattform und lässt sich debuggen, wenn etwas schiefgeht.
Fairerweise: Was No-Code richtig gut kann
Wer schon mal eine Slack-Anbindung oder eine Google-Sheets-Synchronisation selbst programmiert hat, weiß, wie viel Boilerplate das ist. In n8n oder Make klickt man sich das in zehn Minuten zusammen. Hunderte Konnektoren sind fertig, die Community liefert Templates für fast jeden Standard-Use-Case, und ein funktionierender Prototyp steht oft am selben Nachmittag. Für Teams ohne eigene Entwickler ist das häufig der einzige realistische Weg zur Automatisierung.
Der Wechsel zu eigenem Code war kein Grundsatzurteil, sondern eine Konsequenz aus unserem spezifischen Problem: Echtzeit-Telefonie mit Mandantentrennung und Monitoring über die gesamte Pipeline.
Unser Rat: Fangt mit No-Code an, wenn der Prozess einfach und unkritisch ist. Aber plant den Wechsel ein, sobald ihr mehr Zeit mit Workarounds für die Tool-Grenzen verbringt als mit eurem eigentlichen Problem.