Wer heute Automatisierung mit KI plant, stolpert schnell über dieselbe Frage: Nehme ich Make.com, n8n oder Zapier — oder baue ich etwas Eigenes? Die Antwort hängt weniger von Technologie-Präferenzen ab als von drei harten Faktoren: Kosten, internes Know-how und wie eng die Prozesse an die Plattform gebunden sein dürfen.
Dieser Artikel richtet sich an Firmen mit 30 bis 80 Mitarbeitern. Keine Enterprise-Budgets, kein dediziertes Entwicklungsteam — aber klarer Bedarf, repetitive Arbeit zu automatisieren.
Was Low-Code-Plattformen wirklich kosten
Make.com kostet auf dem Team-Plan 29 USD pro Monat für 10.000 Operationen. Klingt günstig. Wird aber schnell teurer, sobald echte Volumen kommen. Ein mittelgroßes Szenario — etwa eingehende E-Mails klassifizieren, in CRM schreiben, Antwort-Entwurf per GPT generieren — verbraucht pro Durchlauf leicht 15 bis 30 Operationen. Bei 500 solcher Vorgänge pro Monat sind das 7.500 bis 15.000 Operationen. Noch im Rahmen. Bei 2.000 Vorgängen ist man mit 40.000 Operationen bereits im Pro-Plan (59 USD) oder darüber.
Zapier ist teurer: Der Professional-Plan startet bei 49 USD, mit KI-Schritten (also OpenAI-Aufrufen über Zapier) steigen die Task-Kosten spürbar. n8n hingegen ist Open Source — selbst gehostet auf einem kleinen VPS zahlt man vielleicht 10–20 USD im Monat für den Server, dafür braucht jemand die Zeit zur Wartung.
Häufiges Muster bei einem Handelsunternehmen mit 55 MA: Make.com startet mit dem günstigen Plan, läuft sechs Monate gut, dann wächst das Szenario-Portfolio. Plötzlich sind vier verschiedene Workflows aktiv, jeder mit eigenem GPT-Aufruf. Der Monatspreis verdreifacht sich, ohne dass irgendjemand das bewusst entschieden hat.
Was „selbstgebaut” konkret bedeutet
Selbstgebaut heißt nicht zwingend, dass ein Softwareentwickler Vollzeit beschäftigt wird. Es gibt ein Spektrum:
Option A — n8n selbst gehostet: Open-Source-Workflow-Engine, Docker-Container auf einem VPS oder einer kleinen Cloud-Instanz. Wer einmal Docker eingerichtet hat, kommt damit zurecht. Laufende Kosten: 15–40 USD/Monat für den Server. Einmaliger Aufwand für Setup: 4–8 Stunden. Wartung: Updates einspielen, gelegentlich Logs prüfen.
Option B — Python-Skripte plus Cronjob: Für einfache, lineare Prozesse oft die ehrlichste Lösung. Ein Skript, das täglich Daten aus einer API holt, per OpenAI verarbeitet und in eine Tabelle schreibt, hat 50 Zeilen Code. Wartungsaufwand pro Jahr: ein halber Tag. Voraussetzung: jemand im Team kann Python lesen und schreiben.
Option C — Eigener Microservice: FastAPI oder Flask, deployed auf einem kleinen Server oder einer Serverless-Umgebung. Sinnvoll, wenn mehrere Systeme auf denselben Prozess zugreifen sollen oder wenn eigene Datenhaltung nötig ist. Aufwand zur Erstellung: 1–3 Tage. Langfristig wartungsintensiver.
Aus meiner Sicht ist Option A für die meisten 50-MA-Firmen der sweet spot zwischen Flexibilität und Aufwand — sofern jemand da ist, der nicht panisch wird, wenn ein Docker-Container neugestartet werden muss.
Der entscheidende Faktor: internes Know-how
Die Technologieentscheidung ist zweitrangig gegenüber der Personalfrage. Typisches Beispiel: Ein Steuerberater mit 18 MA baut auf Make.com, weil niemand in der Kanzlei technisch tief genug drin ist, um n8n zu betreiben. Das ist die richtige Entscheidung. Die Plattform kostet 59 USD/Monat, läuft stabil, und der steuerliche Mehrwert überwiegt die Lizenzkosten bei weitem.
Anders sieht es bei einem Maschinenbauer mit 75 MA aus, der einen internen IT-Administrator hat. Hier ist der Aufbau auf n8n oder einem Python-basierten Stack sinnvoll — bessere Kontrolle über Daten, kein Lock-in, und der Admin kann es warten.
Die Frage, die ich immer stelle: Wenn die Person, die den Workflow gebaut hat, morgen nicht mehr im Unternehmen ist — wer pflegt ihn dann? Bei Make.com kann das fast jede technisch interessierte Person nach einer Stunde Einarbeitung. Bei einem selbstgebauten Python-Dienst braucht man jemanden, der Python kann.
Lock-in: Wie schlimm ist er wirklich?
Lock-in bei Low-Code-Plattformen ist real, aber oft überschätzt. Was tatsächlich problematisch ist:
- Proprietäre Logik: Komplexe Bedingungen, Fehlerbehandlung und Loops in Make.com sind nur innerhalb von Make.com portierbar. Ein aufwändiges Szenario mit 40 Modulen lässt sich nicht per Export auf n8n übertragen — das muss neu gebaut werden.
- Datenspeicherung auf der Plattform: Wer Make.com-eigene Datenspeicher nutzt, hat die Daten auf fremden Servern. Bei sensiblen Geschäftsdaten ein Problem.
- Preisänderungen: Make.com hat 2023 die Preispolitik geändert. Wer stark auf die Plattform aufgebaut hat, kann nicht kurzfristig wechseln.
Mein Rat: Low-Code ist akzeptabel für Prozesse, die klein bleiben und keine sensiblen Daten verarbeiten. Sobald ein Workflow geschäftskritisch wird oder täglich Tausende von Datensätzen verarbeitet, lohnt sich die Überlegung, ihn selbst zu betreiben.
Kosten im direkten Vergleich — Beispielrechnung
Szenario: Eingehende Anfragen per E-Mail werden klassifiziert, einer Kategorie zugewiesen und ein Entwurf für die Antwort wird per GPT-4o erstellt. Volumen: 1.500 Vorgänge/Monat.
Make.com (Pro-Plan):
- Plattform: 59 USD/Monat
- OpenAI-API-Kosten (GPT-4o, ca. 500 Token pro Vorgang): ~4,50 USD/Monat
- Setup-Aufwand einmalig: 1 Tag intern
- Gesamt laufend: ca. 65 USD/Monat
n8n selbst gehostet + OpenAI direkt:
- Server (2 vCPU, 4 GB RAM): 20 USD/Monat
- OpenAI-API: ~4,50 USD/Monat
- Setup-Aufwand einmalig: 1,5 Tage intern
- Wartung: ca. 1 Stunde/Monat
- Gesamt laufend: ca. 25 USD/Monat + Wartungszeit
Python-Skript auf VPS:
- Server: 10 USD/Monat (klein, da einfacher Prozess)
- OpenAI-API: ~4,50 USD/Monat
- Setup-Aufwand einmalig: 2 Tage Entwicklung
- Wartung: ca. 30 Minuten/Monat
- Gesamt laufend: ca. 15 USD/Monat + Wartungszeit
Der Unterschied bei 1.500 Vorgängen ist überschaubar. Bei 15.000 Vorgängen pro Monat sieht die Make.com-Rechnung schon anders aus — dann kostet allein die Plattform 299 USD/Monat (Teams-Plan mit ausreichend Operationen).
Wann Low-Code, wann selbst gebaut?
Low-Code macht Sinn wenn:
- Kein technisches Personal vorhanden oder verfügbar
- Prozesse sind einfach und stabil
- Schnell testen ist wichtiger als langfristige Optimierung
- Budget unter 100 USD/Monat, Volumen moderat
- Datenschutz ist kein kritisches Thema (oder Daten verlassen das System nicht)
Selbst gebaut macht Sinn wenn:
- Interner Admin oder Entwickler vorhanden
- Prozesse sind komplex oder werden wachsen
- Sensible Daten (Kundendaten, Finanzdaten) im Spiel
- Langfristige Kostenoptimierung relevant
- Mehrere Systeme sollen auf dieselbe Logik zugreifen
Hybride Ansätze in der Praxis
Häufiges Muster bei wachsenden KMU: Start mit Make.com für erste Prototypen und Validierung, dann schrittweise Migration der geschäftskritischen Workflows auf n8n oder eigene Services. Die einfachen, unkritischen Prozesse bleiben auf Make.com — das ist keine Schwäche, sondern pragmatisch.
Beispielhaft: Ein Onlinehändler mit 45 MA automatisiert zuerst die Bestellbestätigung per Make.com (einfach, unkritisch, schnell live). Den KI-gestützten Support-Routing-Prozess baut er sechs Monate später selbst — weil er täglich 800 Tickets verarbeitet und die Make.com-Kosten auf 200 USD/Monat gestiegen wären.
Was oft unterschätzt wird: Prompt-Management
Unabhängig vom Stack: Die eigentliche Arbeit liegt im Prompt-Design und im kontinuierlichen Verbessern der KI-Ausgaben. Ein gut strukturierter Prozess auf Make.com, der mit sorgfältig getesteten Prompts arbeitet, liefert bessere Ergebnisse als ein selbstgebauter Service mit schlechten Prompts. Die Plattformwahl ist sekundär gegenüber der Qualität der Prompts, der Fehlerbehandlung und der Frage, was mit unerwarteten Ausgaben der KI passiert.
Fazit
Es gibt keine universell richtige Antwort. Für eine 50-MA-Firma ohne technisches Personal ist Make.com oder n8n Cloud die richtige Wahl — Pragmatismus vor Purismus. Wer einen Admin hat, fährt mit n8n selbst gehostet wirtschaftlicher und flexibler. Wer Python-Kompetenz im Haus hat, sollte für einfache, lineare Prozesse direkt zu Skripten greifen.
Wichtigste Regel: Entscheiden Sie sich für eine Option und bauen Sie darauf konsequent auf. Wer alle drei Varianten gleichzeitig betreibt, hat dreifachen Wartungsaufwand und kein durchgängiges System.