Wann No-Code zur falschen Wahl wird: die Grenze, an der echter Code günstiger ist

"Können wir das nicht einfach in Make bauen?"

Die Frage kam von einem CTO, dessen Team gerade vier Wochen damit verbracht hatte, genau das zu versuchen. Ein Szenario, das Bestellungen aus dem Shop nahm, sie gegen das ERP prüfte, Teillieferungen aufsplittete, Preisstaffeln rechnete und das Ergebnis an drei Systeme zurückschrieb. Auf dem Whiteboard hatte das nach einem Nachmittag Arbeit ausgesehen. In Make war daraus ein Szenario mit 140 Modulen geworden, das niemand mehr im Kopf hatte, das bei jedem dritten Lauf an einer anderen Stelle abbrach und dessen monatliche Operations-Rechnung höher lag als das Gehalt eines Werkstudenten.

Wir haben uns das Ding eine Stunde lang angeschaut und dann gesagt, was wir in solchen Fällen oft sagen: Das gehört nicht mehr in ein No-Code-Tool. Das gehört in zweihundert Zeilen Code.

Diese Antwort überrascht Kunden, weil wir ein Haus sind, das No-Code aktiv empfiehlt und in den meisten Projekten einsetzt. Aber genau deshalb wissen wir, wo die Grenze liegt. Und die Grenze ist konkreter, als die meisten glauben. Sie ist kein Bauchgefühl und keine Geschmacksfrage zwischen Klick und Tastatur. Sie ist ein Muster, das sich an vier Stellen zeigt, und wer es kennt, trifft die Entscheidung Monate früher, bevor das Szenario auf 140 Module angewachsen ist.

Warum No-Code fast immer der richtige Start ist

Bevor ich über die Grenze rede, muss klar sein, warum No-Code überhaupt unser Standard ist. Denn der Reflex mancher Entwickler, alles sofort in Code zu gießen, ist genauso teuer wie der umgekehrte.

No-Code ist schnell. Was in Make oder n8n an einem Vormittag steht, braucht als sauber deployter Service mit Tests, Logging und Fehlerbehandlung mehrere Tage. Für einen Workflow, der eine Tabelle synchronisiert oder eine Mail bei einem neuen Lead verschickt, ist dieser Aufwand absurd.

No-Code ist sichtbar. Ein Make-Szenario kann eine Sachbearbeiterin lesen, die nie programmiert hat. Sie sieht die Boxen, sie sieht die Pfeile, sie versteht in groben Zügen, was passiert. Code ist für die Fachabteilung eine Blackbox. Diese Lesbarkeit ist im Tagesgeschäft mehr wert, als Entwickler oft zugeben.

No-Code hat kein Deployment. Keine Pipeline, kein Server, kein Container, der nachts neu startet und nicht mehr hochkommt. Die Plattform kümmert sich um Laufzeit, Skalierung und Verfügbarkeit. Für ein kleines Team ohne eigene Operations ist das ein gewaltiger Vorteil, den man erst zu schätzen lernt, wenn man die Alternative selbst betreiben muss.

Und No-Code zwingt zur Einfachheit. Solange ein Prozess in zwanzig Module passt, ist er meistens auch wirklich einfach. Die Plattform ist eine natürliche Komplexitätsbremse. Das ist ein Feature, kein Bug.

Für vielleicht achtzig Prozent dessen, was Unternehmen automatisieren wollen, ist das die richtige Antwort. Die spannenden Fälle sind die anderen zwanzig Prozent, und um die geht es hier.

Signal eins: Die Verzweigungslogik explodiert

Das erste und zuverlässigste Zeichen ist die Zahl der Wenn-Dann-Pfade.

Ein gesunder Workflow hat eine Handvoll Verzweigungen. Lead ist aus Deutschland oder nicht. Rechnung ist über oder unter einem Schwellwert. Kunde hat ein Feld gesetzt oder nicht. Solange Sie diese Pfade an einer Hand abzählen können, ist die visuelle Darstellung ein Gewinn, weil sie die Logik sichtbar macht.

Der Ärger beginnt, wenn die Pfade sich multiplizieren. Bei unserem Bestell-Szenario gab es Volllieferung und Teillieferung, Bestandskunde und Neukunde, drei Preisstaffeln, vier Versandländer mit unterschiedlicher Steuerlogik und einen Sonderfall für Retouren. Das sind keine vier Verzweigungen mehr, das sind Dutzende Kombinationen, und jede einzelne braucht im visuellen Editor ihre eigene Box, ihren eigenen Pfad, ihre eigene Wartung.

In Code ist eine Preisberechnung mit vier Staffeln und mehreren Sonderfällen eine Funktion mit ein paar Verzweigungen, die man auf einen Bildschirm bekommt und in fünf Minuten liest. Im visuellen Editor wird daraus eine Landschaft, durch die man scrollen muss und die man nie ganz überblickt. Die visuelle Darstellung, die bei einfacher Logik hilft, wird bei verschachtelter Logik zum Hindernis.

Die Faustregel, die wir intern benutzen: Wenn Sie anfangen, dieselbe Verzweigungslogik an mehreren Stellen im Szenario zu kopieren, weil es keinen sauberen Weg gibt, sie einmal zu definieren und wiederzuverwenden, haben Sie die Komfortzone von No-Code verlassen. Code kennt Funktionen. Visuelle Editoren kennen Copy-Paste, und Copy-Paste ist der Anfang vom Ende jeder Wartbarkeit.

Signal zwei: Sie kämpfen gegen das Werkzeug, nicht gegen das Problem

Jedes No-Code-Tool hat Dinge, die es nicht gut kann. Datentransformationen über verschachtelte Strukturen. Das Zusammenführen von zwei Listen anhand eines Schlüssels. Das Iterieren über eine variable Zahl von Elementen mit eigenem Zustand pro Durchlauf. Das Behandeln von Sonderzeichen, Encodings und kaputtem JSON.

Es gibt für all das Workarounds. Man kann in Make ein iteratives Array mit einem Aggregator zusammenbauen, man kann in n8n einen Function-Node einsetzen, man kann Daten durch drei Module schieben, um sie umzuformen. Aber irgendwann merken Sie, dass Sie die meiste Zeit nicht mehr am eigentlichen Geschäftsproblem arbeiten, sondern daran, das Tool zu überlisten.

Das ist ein verräterisches Gefühl, und wir nehmen es ernst. Wenn ein Entwickler in einem Projekt sagt, er hätte das in Python in zwanzig Minuten gehabt, aber er sitze jetzt seit zwei Stunden an einer Make-Konstruktion, die dasselbe tut, dann ist das kein Zeichen mangelnden Könnens. Es ist ein Zeichen, dass das Werkzeug nicht zum Problem passt.

Besonders deutlich wird das bei einem Muster, das wir den Function-Node-Schwerpunkt nennen. Viele No-Code-Plattformen erlauben es, an einzelnen Stellen Code einzubetten. Ein bisschen JavaScript hier, ein kleines Python-Snippet da. Das ist als Notausgang gedacht. Wenn aber die Hälfte der Wertschöpfung Ihres Szenarios in diesen eingebetteten Code-Blöcken steckt und die visuellen Module nur noch Daten von einem Snippet zum nächsten reichen, dann benutzen Sie ein No-Code-Tool als schlechte IDE. Der Code ist da, er ist nur über ein Dutzend winziger Editierfenster verstreut, ohne Versionierung, ohne Tests, ohne die Möglichkeit, ihn lokal auszuführen.

An diesem Punkt ist die ehrliche Frage nicht mehr, wie Sie den nächsten Function-Node bauen, sondern warum der Code nicht einfach in einer Datei liegt, in der man ihn vernünftig lesen kann.

Signal drei: Die Kosten pro Lauf skalieren in die falsche Richtung

No-Code-Plattformen rechnen pro Operation oder pro Task. Solange das Volumen niedrig ist, ist das billig und planbar. Bei steigendem Volumen kippt die Rechnung, und sie kippt überraschend schnell.

Make zählt jedes Modul, das ausgeführt wird, als Operation. Ein Szenario mit 140 Modulen, das pro Bestellung läuft, verbraucht im schlechtesten Fall 140 Operationen pro Bestellung. Bei tausend Bestellungen am Tag sind das 140.000 Operationen täglich, über vier Millionen im Monat. Das ist eine Größenordnung, in der die Plattform-Rechnung von einem netten Posten zu einer ernsthaften Kostenposition wird.

Derselbe Prozess als eigener Service kostet Sie einen kleinen Server, der konstant ein paar Euro im Monat verbraucht, egal ob Sie hundert oder hunderttausend Bestellungen verarbeiten. Die Kostenkurve von No-Code steigt mit dem Volumen. Die Kostenkurve von Code ist fast flach. Es gibt einen Schnittpunkt, und ab diesem Schnittpunkt zahlen Sie für die Bequemlichkeit von No-Code einen Aufpreis, der nicht mehr zu rechtfertigen ist.

Den Schnittpunkt kann man ausrechnen. Wir machen das in Projekten regelmäßig: aktuelle Operationen pro Monat, Kosten pro Operation, projiziertes Wachstum auf zwölf Monate. Auf der anderen Seite die einmaligen Entwicklungskosten für einen Service plus laufender Betrieb. Bei vielen Workflows liegt der Schnittpunkt so weit in der Zukunft, dass er nie erreicht wird, und dann bleibt No-Code richtig. Bei volumenstarken Kernprozessen liegt er oft schon im ersten Jahr.

Ein Punkt, den viele übersehen: Es geht nicht nur um die Plattform-Gebühr. Ein Szenario mit 140 Modulen, das ständig an wechselnden Stellen scheitert, kostet auch Arbeitszeit. Jemand muss die Fehler nachverfolgen, manuell nacharbeiten, die kaputten Läufe neu starten. Diese verdeckten Kosten tauchen in keiner Plattform-Rechnung auf, sind aber oft höher als die Gebühr selbst.

Signal vier: Niemand kann das Ding mehr testen

Das ist die Grenze, die am meisten weh tut, weil sie sich am längsten verstecken lässt.

Ein kleines No-Code-Szenario testet man, indem man es einmal laufen lässt und schaut, ob das Richtige passiert. Bei zwanzig Modulen geht das. Bei 140 Modulen mit Dutzenden Verzweigungen geht es nicht mehr. Sie können nicht jeden Pfad durchspielen, weil Sie nicht alle Eingabe-Kombinationen herstellen können, ohne echte Bestellungen oder echte Kunden anzufassen. Sie ändern an einer Stelle etwas und wissen nicht, welche der dreißig anderen Pfade Sie damit gerade kaputtgemacht haben.

In Code ist das ein gelöstes Problem. Sie schreiben automatisierte Tests, die alle Sonderfälle einmal durchspielen, und lassen sie bei jeder Änderung laufen. Wenn Sie die Preislogik anfassen und ein alter Fall bricht, sagt der Test es Ihnen in Sekunden. In einem visuellen Editor gibt es dieses Sicherheitsnetz nicht. Jede Änderung an einem großen Szenario ist ein Sprung ins Ungewisse, und Sie merken erst in der Produktion, dass etwas kaputt ist, meistens dann, wenn ein Kunde sich beschwert.

Wir sehen den Effekt in der Praxis als Lähmung. Ab einer gewissen Größe trauen sich Teams nicht mehr, ihre eigenen Szenarien anzufassen. Der Workflow wird zum unantastbaren Monolithen, den keiner ändern will, weil keiner vorhersagen kann, was die Änderung auslöst. Genau dieselbe Angst, die wir bei Zombie-Workflows beschrieben haben, nur dass hier der Workflow noch wichtig ist. Das ist der Moment, in dem ein Werkzeug, das eigentlich für Geschwindigkeit gedacht war, das Tempo komplett ausbremst.

Der ökonomische Kipppunkt

Wenn ich die vier Signale auf eine Frage eindampfen müsste, dann diese: An welchem Punkt kostet das Festhalten an No-Code mehr als der Wechsel zu Code?

Diese Rechnung hat zwei Seiten, die beide oft falsch geschätzt werden.

Die Kosten von No-Code, wenn man es übertreibt, sind die Plattform-Gebühr bei hohem Volumen, die Arbeitszeit für ständige Nacharbeit an einem fragilen Szenario, die verzögerte Entwicklung, weil sich niemand mehr an Änderungen traut, und das Risiko stiller Fehler, die niemand findet, weil das Ding nicht testbar ist. Diese Kosten sind real, aber sie sind verteilt und verdeckt, deshalb unterschätzt man sie systematisch.

Die Kosten von Code, wenn man zu früh wechselt, sind die initiale Entwicklungszeit, die Notwendigkeit, einen Service zu betreiben, zu deployen und zu überwachen, der Verlust an Sichtbarkeit für die Fachabteilung und die Abhängigkeit von Menschen, die programmieren können. Auch diese Kosten sind real, und sie sind sehr sichtbar, deshalb überschätzt man sie.

Der Kipppunkt liegt dort, wo die verdeckten Kosten des Festhaltens die sichtbaren Kosten des Wechsels übersteigen. Bei einem Workflow, der zweimal am Tag eine Tabelle synchronisiert, wird dieser Punkt nie erreicht. Bei einem volumenstarken Kernprozess mit komplexer Logik ist er oft schon überschritten, bevor jemand ihn überhaupt bemerkt.

Unser Job in der Beratung ist nicht, eine Seite zu bevorzugen. Er ist, beide Seiten ehrlich auszurechnen, statt die verdeckten Kosten zu ignorieren, weil sie nicht auf einer Rechnung stehen.

Was "echter Code" hier eigentlich bedeutet

An dieser Stelle bekommen Kunden oft Panik, weil sie sich unter dem Wechsel zu Code etwas Riesiges vorstellen. Ein Entwicklerteam, eine monatelange Migration, ein eigenes System mit allem Drum und Dran. Das ist fast nie gemeint.

In den meisten Fällen, die wir begleiten, bedeutet der Wechsel: Ein einziger Teil des Workflows, der komplexe Kern, wird aus dem No-Code-Szenario herausgelöst und als kleiner Service ausgelagert. Bei dem Bestell-Beispiel war das die Preis- und Lieferlogik. Zweihundert Zeilen Python, die eine Bestellung entgegennehmen, die ganze Berechnung machen und ein sauberes Ergebnis zurückgeben. Mehr nicht.

Der Rest blieb in Make. Das Szenario nahm weiter den Webhook aus dem Shop entgegen, rief den neuen Service mit den Bestelldaten auf, bekam das fertige Ergebnis zurück und verteilte es an die drei Zielsysteme. Aus 140 Modulen wurden ungefähr fünfzehn. Die fünfzehn, die in einem visuellen Editor gut aufgehoben sind, weil sie einfach Daten von A nach B bewegen. Der eine harte Teil, die Logik, lag jetzt in Code, mit Tests, mit Versionierung, lokal ausführbar.

Das ist der entscheidende Gedanke. Der Wechsel zu Code ist selten eine Alles-oder-nichts-Entscheidung. Er ist meistens das Herausschneiden des einen Teils, der nicht ins Tool passt, während der Rest bleibt, wo er ist. Sie ersetzen nicht das Werkzeug, Sie geben ihm das zurück, was es gut kann, und nehmen ihm das ab, was es schlecht kann.

Das Hybrid-Modell, das wir tatsächlich bauen

Aus dieser Einsicht ist über die Jahre ein Standardmuster geworden, das wir inzwischen in vielen Projekten einsetzen. Wir nennen es intern den orchestrierten Service.

Die No-Code-Plattform übernimmt die Orchestrierung. Sie hört auf Trigger, sie spricht mit den vielen verschiedenen Systemen, sie kümmert sich um die Verbindungen, Authentifizierungen und Webhooks. Das kann Make oder n8n hervorragend, und niemand will diese ganze Konnektoren-Arbeit selbst in Code nachbauen.

Die eigentliche Geschäftslogik, der Teil mit den vielen Verzweigungen, den Berechnungen, den Sonderfällen, liegt in einem oder mehreren kleinen Services, die über einen einfachen Endpunkt erreichbar sind. Die Plattform ruft sie auf wie jede andere API auch.

Dieses Modell verbindet die Stärken beider Welten. Die Fachabteilung sieht im visuellen Editor immer noch, was grob passiert, welche Systeme beteiligt sind und in welcher Reihenfolge. Die harte Logik ist sauber gekapselt, testbar und versioniert. Und wenn sich die Logik ändert, ändert man den Service, ohne das Orchestrierungs-Szenario anzufassen, und umgekehrt.

Der schöne Nebeneffekt: Der Service ist portabel. Wenn Sie irgendwann von Make zu n8n wechseln oder die Plattform ganz verlassen wollen, wandert die wertvolle Logik mit, weil sie nicht in proprietären Modulen gefangen ist. Das ist gelebter Schutz gegen Vendor Lock-in, ohne dass Sie auf den Komfort der Plattform verzichten müssen.

Die Schnittstelle ist der Teil, den man unterschätzt

Wenn die Plattform den ausgelagerten Service über einen Endpunkt aufruft, entsteht eine neue Bruchstelle, die es vorher nicht gab. Im reinen No-Code-Szenario lief alles in einem System. Jetzt reden zwei Systeme miteinander, und alles, was zwischen zwei Systemen schiefgehen kann, kann hier schiefgehen. Der Service antwortet langsam. Der Service ist gerade nicht erreichbar, weil er neu deployt wird. Die Anfrage läuft in einen Timeout. Die Verbindung bricht mitten in der Antwort ab.

Wer diese Fälle nicht von Anfang an mitdenkt, tauscht ein bekanntes Problem gegen ein neues. Deshalb klären wir bei jeder Auslagerung vier Dinge an der Schnittstelle, bevor die erste Zeile Logik geschrieben wird.

Erstens, das Timeout-Verhalten. Was tut das Szenario, wenn der Service nach fünf Sekunden nicht geantwortet hat? Wartet es weiter, bricht es ab, versucht es erneut? Die Antwort hängt davon ab, ob der Aufruf etwas verändert oder nur etwas berechnet. Eine reine Berechnung darf man gefahrlos wiederholen. Ein Aufruf, der nebenbei eine Rechnung schreibt, nicht.

Zweitens, die Idempotenz. Wenn das Szenario einen Aufruf wiederholt, weil die erste Antwort ausblieb, darf der Service nicht zweimal dasselbe tun. Wir geben jedem Aufruf eine eindeutige Kennung mit, und der Service merkt sich, welche Kennungen er schon verarbeitet hat. Das ist dasselbe Prinzip, das wir an anderer Stelle für Webhooks beschrieben haben, nur diesmal zwischen Plattform und eigenem Code.

Drittens, ein sauberer Fehlervertrag. Der Service soll im Fehlerfall nicht einfach abstürzen, sondern eine klare, maschinenlesbare Antwort zurückgeben. Was ist schiefgegangen, ist der Fehler dauerhaft oder vorübergehend, darf die Plattform es noch einmal versuchen. Mit dieser Antwort kann das Szenario sinnvoll reagieren, statt blind in die nächste Stufe zu laufen.

Viertens, die Version. Sobald der Service produktiv läuft, wird er sich ändern. Verschiebt sich dabei das Format der Antwort, bricht das Szenario, das die alte Antwort erwartet. Wir versehen die Schnittstelle deshalb mit einer Version und ändern das Format nie still. Lieber eine zweite Version daneben, die das Szenario in Ruhe nachzieht, als eine stille Änderung, die am Sonntag auffällt.

Diese vier Punkte klingen nach Mehraufwand, und das sind sie auch. Aber sie sind genau der Teil, der entscheidet, ob die Auslagerung das Setup stabiler oder fragiler macht. Eine schlecht gebaute Schnittstelle nimmt Ihnen die Vorteile von Code und legt Ihnen die Nachteile verteilter Systeme obendrauf.

Eine konkrete Migration

Damit das nicht abstrakt bleibt, der Verlauf bei dem Bestell-Szenario, von dem ich oben erzählt habe.

Wir haben nicht sofort gebaut. Im ersten Schritt haben wir das bestehende 140-Module-Szenario eine Woche lang beobachtet und protokolliert, an welchen Stellen es scheiterte. Das Ergebnis war eindeutig: Über neunzig Prozent der Fehler passierten in dem Block, der die Preisstaffeln und Teillieferungen berechnete. Der Rest des Szenarios, der die Daten empfing und verteilte, lief stabil.

Damit war klar, was herausgeschnitten werden musste. Wir haben die Berechnungslogik in einen kleinen Service überführt, in der Sprache, die das Team ohnehin beherrschte. Zwei Tage Entwicklung, ein Tag für die Tests, in denen wir jeden Sonderfall einmal durchspielten, auch die, die im alten Szenario nie sauber getestet worden waren.

Dann haben wir das Make-Szenario umgebaut. Der ganze Berechnungs-Block flog raus und wurde durch einen einzigen HTTP-Aufruf ersetzt, der den neuen Service anstieß. Aus 140 Modulen wurden vierzehn. Wir haben beide Versionen zwei Wochen parallel laufen lassen, das alte Szenario im Schreibmodus, den neuen Pfad im Testmodus, und die Ergebnisse verglichen. Als sie über Hunderte Bestellungen übereinstimmten, haben wir umgeschaltet.

Das Resultat nach drei Monaten: Die Fehlerquote fiel von jedem dritten Lauf auf nahezu null. Die Make-Rechnung sank um mehr als die Hälfte, weil die teuren Berechnungs-Module weg waren. Und, das war dem Team fast am wichtigsten, jemand traute sich endlich wieder, die Preislogik zu ändern, weil die Tests jede Änderung absicherten.

Die Gesamtkosten der Migration, Entwicklung plus Beratung, waren nach gut vier Monaten durch die eingesparte Plattform-Gebühr und die wegfallende Nacharbeit wieder drin. Danach war es reiner Gewinn.

Was Sie verlieren, wenn Sie auf Code wechseln

Ich will hier nicht einseitig sein, denn der Wechsel kostet auch etwas, und wer das verschweigt, verkauft unehrlich.

Sie verlieren Sichtbarkeit für Nicht-Entwickler. Der ausgelagerte Service ist für die Fachabteilung eine Blackbox. Wo vorher jemand ohne Programmierkenntnisse grob nachvollziehen konnte, was die Berechnung tut, steht jetzt ein Endpunkt, in den nur Entwickler hineinschauen können. Das ist ein echter Verlust, und man muss ihn durch gute Dokumentation und klare Schnittstellen abfedern.

Sie bekommen ein Stück Betrieb zurück. Ein Service muss irgendwo laufen. Er muss deployt, überwacht und bei Bedarf neu gestartet werden. Die Plattform hat Ihnen diese Arbeit abgenommen, jetzt liegt sie zumindest teilweise wieder bei Ihnen. Bei einem kleinen, zustandslosen Service ist dieser Aufwand gering, aber er ist nicht null.

Und Sie schaffen eine Abhängigkeit von Menschen, die programmieren können. Solange alles in Make lag, konnte im Notfall jemand mit etwas Einarbeitung eingreifen. Beim ausgelagerten Service brauchen Sie jemanden, der den Code versteht. In einem kleinen Team ohne festen Entwickler ist das ein Risiko, das man bewusst eingehen muss.

Diese drei Punkte sind der Grund, warum wir nicht reflexhaft zu Code raten. Sie sind der Preis, und der Preis lohnt sich nur, wenn die vier Signale wirklich da sind.

Was Sie gewinnen

Auf der anderen Seite der Rechnung steht das, was Sie zurückbekommen.

Testbarkeit, und damit das Vertrauen, Dinge zu ändern, ohne in Angst zu leben. Das ist der größte Einzelgewinn, und Teams unterschätzen ihn, bis sie ihn zum ersten Mal erleben. Eine Änderung, bei der ein Test sofort sagt, ob etwas kaputt ging, fühlt sich fundamental anders an als eine Änderung, bei der man hofft, dass die Produktion es überlebt.

Vorhersehbare Kosten, die mit dem Volumen nicht mehr in die Höhe schießen. Ein Service kostet ungefähr dasselbe, ob er hundert oder hunderttausend Mal am Tag läuft. Bei volumenstarken Prozessen ist das der finanzielle Hauptgrund für den Wechsel.

Echte Versionierung. Sie sehen, wer wann was geändert hat, Sie können auf einen alten Stand zurück, Sie können Änderungen vor dem Ausrollen prüfen. All das, was in einem visuellen Editor entweder gar nicht oder nur rudimentär geht, ist bei Code Standard.

Und Portabilität. Die Logik gehört Ihnen, nicht der Plattform. Sie hängt nicht an proprietären Modulen, die es nur in einem Werkzeug gibt. Das macht Sie freier in jeder zukünftigen Entscheidung über Ihren Stack.

Drei Fehler, die wir bei Auslagerungen immer wieder sehen

Wenn ein Team sich einmal für den Wechsel entschieden hat, gibt es drei Arten, ihn zu vermasseln. Wir kennen sie, weil wir sie aufräumen mussten.

Der erste Fehler ist, zu viel auf einmal herauszuschneiden. Teams, die überzeugt sind, dass Code die Antwort ist, wollen oft gleich das halbe Szenario auslagern. Damit holen sie sich die ganze Komplexität auf einen Schlag ins eigene Haus. Wir schneiden immer nur den einen Block heraus, der die meisten Fehler produziert, und schauen, ob es besser wird, bevor wir den nächsten anfassen. Eine Auslagerung in zwei kleinen Schritten ist fast immer einfacher als eine in einem großen.

Der zweite Fehler ist, die Orchestrierung mit auszulagern. Manche bauen den Service so, dass er nicht nur rechnet, sondern gleich auch die Zielsysteme selbst anspricht. Damit verlagert man die Konnektoren-Arbeit, die die Plattform gut kann, in eigenen Code, den man pflegen muss. Der Service soll rechnen und ein Ergebnis zurückgeben, mehr nicht. Das Reden mit den anderen Systemen bleibt bei der Plattform, wo es hingehört.

Der dritte Fehler ist, den Service ohne Überwachung live zu nehmen. Ein No-Code-Szenario sieht man in der Plattform laufen, ein eigener Service arbeitet still im Hintergrund. Wenn niemand misst, ob er antwortet und wie schnell, bemerkt man einen Ausfall erst, wenn das Szenario reihenweise scheitert. Ein einfacher Health-Check und eine Nachricht, sobald die Antwortzeiten ausreißen, gehören vom ersten Tag an dazu.

Die Fragen, die wir vor jedem Wechsel stellen

Wenn ein Kunde mit einem großen, fragilen Szenario zu uns kommt, raten wir nicht sofort. Wir gehen vier Fragen durch.

Erstens: Wie viele der Fehler der letzten Wochen konzentrieren sich auf einen bestimmten Teil des Szenarios? Wenn neunzig Prozent in einem Block passieren, ist das der Kandidat zum Herausschneiden. Wenn die Fehler gleichmäßig verteilt sind, ist das Problem oft kein Code-Problem, sondern ein Datenproblem, und dann hilft Code nicht.

Zweitens: Wie sieht das Volumen in zwölf Monaten aus? Bei einem Prozess, der heute fünfzig Mal am Tag läuft und nächstes Jahr fünftausend Mal, sieht die Kostenrechnung völlig anders aus als bei einem, der konstant niedrig bleibt. Der Wechsel ist eine Wette auf die Zukunft, und die Wette muss man explizit machen.

Drittens: Wer pflegt den Service danach? Wenn die Antwort lautet, dass es im Unternehmen niemanden gibt, der Code übernehmen kann, ist die Auslagerung ein Bumerang. Dann bleiben wir lieber bei No-Code und optimieren das Szenario, so gut es geht, oder klären die Wartung verbindlich vorab.

Viertens: Lässt sich der harte Teil sauber abgrenzen? Manche Szenarien sind verschachtelt, dass es keinen klaren Schnitt gibt. Wenn die komplexe Logik untrennbar mit den vielen Konnektoren verwoben ist, ist die Auslagerung aufwendiger und der Gewinn kleiner. Je sauberer der harte Kern abgrenzbar ist, desto leichter und lohnender ist der Wechsel.

Erst wenn diese vier Fragen in Richtung Code zeigen, bauen wir. Sonst bleibt es bei No-Code, und das ist häufiger der Fall, als die Code-Fraktion glauben möchte.

Der Fehler, zu früh zu wechseln

Genauso oft wie das zu späte Festhalten sehen wir den umgekehrten Fehler, und der kommt fast immer von Entwicklern.

Ein technisch versierter Mitarbeiter schaut sich ein Make-Szenario an, verzieht das Gesicht und sagt, das hätte er in Code sauberer. Vermutlich stimmt das sogar. Aber sauberer heißt nicht wirtschaftlicher. Für einen Workflow, der zweimal am Tag eine Handvoll Datensätze bewegt, ist ein deployter Service mit Pipeline und Monitoring maßlos übertrieben. Die Entwicklungszeit holt sich der Prozess in seinem ganzen Leben nicht wieder rein.

Der Reflex, alles in Code zu gießen, weil Code sich für Entwickler richtiger anfühlt, ist genauso ein Antimuster wie das Festhalten an einem 140-Module-Monster. Beide ignorieren die eigentliche Frage, nämlich was den Prozess über seine gesamte Lebensdauer am wenigsten kostet, in Geld, in Zeit und in Risiko.

Die ehrliche Haltung ist langweilig: No-Code ist der Default. Code ist die begründete Ausnahme. Die Kunst liegt nicht darin, eine Seite zu lieben, sondern den Kipppunkt zu erkennen und ihn nicht zu früh und nicht zu spät zu überschreiten.

Wo die Grenze für Sie liegt

Wenn Sie ein Szenario haben, das größer und fragiler geworden ist, als es sein sollte, lohnt sich der nüchterne Blick auf die vier Signale. Explodiert die Verzweigungslogik? Kämpfen Sie gegen das Werkzeug statt gegen das Problem? Skalieren die Kosten in die falsche Richtung? Traut sich niemand mehr, das Ding anzufassen?

Ein oder zwei dieser Signale sind ein Grund, genauer hinzuschauen. Drei oder vier sind ein Grund zu handeln. Und handeln heißt fast nie, alles neu zu bauen. Es heißt, den einen harten Teil herauszuschneiden und dem Werkzeug zurückzugeben, was es gut kann.

Falls Sie unsicher sind, ob eines Ihrer Szenarien diese Grenze schon überschritten hat oder ob es nur eine Optimierung braucht, lohnt sich ein Blick in unseren kostenlosen Automations-Check. Wir schauen uns Ihre größten Workflows gemeinsam an, prüfen die vier Signale und sagen Ihnen ehrlich, ob ein Stück Code Sie weiterbringt oder ob No-Code für Ihren Fall die richtige Wahl bleibt.