Make, n8n oder Eigenbau: was wann sinnvoll ist

Sobald ein Betrieb anfängt, sich mit Automatisierung zu beschäftigen, taucht diese Frage fast immer auf: Make oder n8n? Meistens ist sie zu früh gestellt — nicht, weil die Tools falsch wären, sondern weil die Wahl des Werkzeugs die zweitwichtigste Entscheidung ist. Die erste ist, ob ein fertiges Automatisierungstool überhaupt die richtige Antwort ist, oder ob eine Individuallösung mehr Sinn ergibt.

Dieser Beitrag ordnet alle drei Wege ein: Make, n8n und Eigenbau — mit den Kriterien, die tatsächlich entscheiden, nicht mit einer Bestenliste.

Die kurze Antwort

Make eignet sich für Teams, die schnell starten wollen, sich mit einer cloudbasierten, visuellen Oberfläche wohlfühlen und keine eigene Infrastruktur betreiben möchten. n8n eignet sich, wenn Datenhoheit wichtig ist — es lässt sich selbst hosten — oder wenn Abläufe komplex genug werden, dass man gelegentlich eigenen Code in einzelne Schritte einbauen will. Eigenbau, also eine speziell programmierte Lösung, lohnt sich dort, wo Standardtools an eine Grenze stoßen: bei sehr spezifischer Logik, hohen Volumina oder wenn die Automatisierung tief in ein bestehendes System eingebettet werden muss. Die Entscheidung hängt weniger vom Tool ab als von drei Fragen: Wie viele Systeme sind beteiligt, wie viele Ausnahmen hat der Ablauf, und wer soll ihn später pflegen können.

Warum die Tool-Frage zu früh kommt

„Wir brauchen Make" oder „wir brauchen n8n" ist oft schon die Antwort auf eine Frage, die noch gar nicht gestellt wurde: Was genau soll automatisiert werden, und wie stabil ist der Ablauf? Ein Tool ist austauschbar. Die Aufnahme des Ist-Zustands — welche Systeme reden miteinander, wo entstehen Ausnahmen, wer muss am Ende freigeben — ist es nicht. Genau das ist der Kern jeder Prozessanalyse, bevor überhaupt ein Werkzeug feststeht.

Make: schnell starten, wenig Verwaltung

Make ist eine cloudbasierte Plattform mit visuellem Baukasten: Module werden per Drag-and-drop zu einem Ablauf verbunden, ohne dass jemand programmieren muss. Das macht Make stark für Teams ohne eigene Entwicklungskapazität, die einen Ablauf zwischen gängigen Diensten — E-Mail, Tabellenkalkulation, CRM, Kalender — schnell verbinden wollen.

Die Grenze liegt dort, wo ein Ablauf sehr spezifisch wird oder große Datenmengen verarbeitet: Weil Make als gehosteter Dienst läuft, hat man weniger Kontrolle über genaue Ausführungsorte und -zeiten der Daten als bei einer selbst gehosteten Lösung — für Betriebe mit strengen Vorgaben zur Datenverarbeitung ein Punkt, den man vorab mit dem Anbieter klären sollte, nicht annehmen sollte.

n8n: mehr Kontrolle, mehr Verantwortung

n8n verfolgt einen ähnlichen Baukasten-Gedanken wie Make, lässt sich aber zusätzlich auf eigener Infrastruktur betreiben. Das ist relevant für Betriebe, die aus Datenschutzgründen wissen müssen, wo ihre Daten verarbeitet werden, oder die ohnehin eigene Server betreiben. n8n erlaubt außerdem, in einzelnen Schritten eigenen Code auszuführen — eine Zwischenstufe zwischen reinem Baukasten und vollständigem Eigenbau.

Der Preis dieser Kontrolle ist Betrieb: Selbst gehostet bedeutet, dass jemand die Instanz aktuell hält, absichert und bei Ausfällen reagiert. Für Betriebe ohne eigene IT-Abteilung ist das ein echter Zusatzaufwand, den man in die Rechnung einbeziehen muss — dazu mehr in Was kostet eine KI-Agentur.

Eigenbau: wenn Standardtools an ihre Grenze stoßen

Eine Individuallösung — speziell für den Ablauf programmiert, ohne Baukasten-Plattform darunter — lohnt sich vor allem in drei Fällen: wenn die Logik so spezifisch ist, dass sie in keinem Standardmodul abgebildet werden kann, wenn sehr hohe Volumina eine performantere Lösung als ein visueller Baukasten erfordern, oder wenn die Automatisierung fest in ein bestehendes System integriert werden muss, statt daneben zu laufen.

Der Nachteil ist Zeit und Abhängigkeit: Eigenbau dauert länger als das Verbinden fertiger Module, und die Pflege hängt an denjenigen, die den Code verstehen. Das ist kein Argument gegen Eigenbau — nur ein Grund, ihn nicht als Standardweg zu wählen, sondern gezielt dort, wo Baukästen tatsächlich nicht ausreichen.

Die drei Kriterien im Überblick

| Kriterium | Make | n8n | Eigenbau | |---|---|---|---| | Startaufwand | niedrig | mittel | hoch | | Kontrolle über Datenverarbeitung | begrenzt (gehostet) | hoch (selbst hostbar) | vollständig | | Passt bei vielen Ausnahmen | eher nicht | teilweise, über Code-Schritte | ja | | Wartung ohne eigene IT | machbar | erschwert | schwierig | | Geeignet für sehr spezifische Logik | begrenzt | teilweise | ja |

Ein Beispiel aus der Praxis

Ein Betrieb aus der Immobilienverwaltung wollte eingehende Schadensmeldungen automatisch in vier verschiedene interne Systeme verteilen — je nach Objekt, Dringlichkeit und zuständigem Hausmeisterteam. Der erste Ansatz war ein reiner Baukasten-Ablauf: E-Mail rein, Systeme befüllt. Das funktionierte für den Normalfall, scheiterte aber an der Zuordnung, sobald eine Meldung mehrere Objekte betraf oder unklar formuliert war — Fälle, die etwa ein Fünftel der Meldungen ausmachten.

Die Lösung war kein Wechsel des Tools, sondern eine Ergänzung: Der Baukasten blieb für die einfachen Fälle, ein zusätzlicher Prüfschritt mit eigener Logik übernahm die unklaren Fälle und legte sie zur kurzen manuellen Bestätigung vor, statt sie falsch zuzuordnen. Das zeigt das eigentliche Muster: Die Frage ist selten „welches Tool", sondern „wo braucht der Ablauf eine Ausnahme-Behandlung, die ein Standardmodul nicht abbildet".

Wo sich keines der drei lohnt

Nicht jeder Ablauf sollte in ein Tool wandern. Vorgänge, die nur wenige Male im Jahr vorkommen, amortisieren den Aufwand der Einrichtung fast nie — unabhängig davon, welches Werkzeug man wählt. Und bei Abläufen mit hohem Anteil an fachlicher Einzelfallprüfung, etwa rechtlicher Bewertung oder individueller Beratung, bringt keine der drei Optionen einen echten Zeitgewinn: Die Automatisierung würde nur die Form ändern, in der jemand dieselbe Prüfung trotzdem durchführen muss. In solchen Fällen ist die richtige Antwort, den Ablauf wie gehabt manuell zu lassen und die Automatisierung dort einzusetzen, wo sie tatsächlich Zeit freisetzt.

Was ein Wechsel später kostet

Eine Entscheidung, die selten mitgedacht wird: Was passiert, wenn ein Ablauf aus einem Baukasten herauswächst? Ein in Make oder n8n gebauter Ablauf lässt sich in der Regel nicht eins zu eins in eine Individuallösung übertragen — die Logik muss neu gedacht werden, weil ein Baukasten anders strukturiert ist als eigener Code. Das ist kein Grund, Baukästen zu meiden, aber ein Grund, bei absehbarem Wachstum realistisch zu planen: Ein Ablauf, der heute zehn Vorgänge pro Woche verarbeitet und in zwei Jahren absehbar hundert, sollte von Anfang an mit einer Architektur gebaut werden, die diesen Sprung verkraftet — auch wenn der Start dadurch etwas länger dauert.

Umgekehrt gilt: Ein Wechsel zwischen Make und n8n ist deutlich unaufwendiger als ein Wechsel zu Eigenbau, weil beide auf demselben Grundprinzip aufbauen. Wer unsicher ist, welches der beiden Baukastentools passt, verliert also weniger, als es beim ersten Blick scheint — die eigentlich teure Entscheidung ist die zwischen Baukasten und Individuallösung, nicht die zwischen den beiden Baukästen.

Der nächste Schritt

Die Tool-Wahl folgt aus dem Ablauf, nicht umgekehrt. Bevor du dich zwischen Make, n8n oder einer Individuallösung entscheidest, lohnt sich ein Blick auf die konkreten Anwendungsfälle, die sich in der Praxis am häufigsten automatisieren lassen — eine Übersicht dazu findest du unter KI-Automatisierung.

Willst du nicht raten, welches Werkzeug zu eurem Ablauf passt: Genau das klärt die Prozessanalyse — kostenlos, 60 bis 90 Minuten, mit einer konkreten Einschätzung statt einer allgemeinen Tool-Empfehlung.