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. n8n-Workflows haben Overhead bei jedem Node-Übergang. Bei einer Pipeline mit fünf bis sechs Stufen summiert sich das. 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. Bei einem produktiven System mit echten Kunden reicht das nicht.
Debugging. Wenn ein Workflow mit 20 Nodes fehlschlägt, zeigt n8n "Fehler in Node 14". In eigenem Code können wir den exakten Zustand jeder Variable loggen, den Fehler in Minuten eingrenzen und gezielt fixen.
Skalierung. Eine n8n-Instanz verarbeitet Workflows sequentiell. Bei fünf Salons auf der Plattform war das kein Problem. Aber ein System, das hunderte Mandanten gleichzeitig bedienen 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.
Wann No-Code trotzdem Sinn ergibt
Wir sind keine No-Code-Gegner. Für interne Prototypen, einfache Benachrichtigungen oder Workflows, die sich selten ändern, sind Tools wie n8n, Zapier oder Make eine gute Wahl. Wir nutzen n8n selbst noch für interne Hilfsprozesse, die nicht geschäftskritisch sind.
Unser Rat: Startet mit No-Code, wenn der Prozess einfach und unkritisch ist. Aber plant den Wechsel zu Code ein, sobald ihr merkt, dass ihr mehr Zeit mit Workarounds für die Tool-Grenzen verbringt als mit eurem eigentlichen Problem.