Relay hat am Donnerstag angekündigt, den Dienst einzustellen.
Free-Nutzer haben bis zum 15. August 2026 Zeit. Zahlende Kunden bis zum 14. September. Bestehende Workflows laufen während der Abwicklungsphase weiter, und Relay hat Möglichkeiten bereitgestellt, die zugrundeliegenden Daten zu exportieren.
Das löst das unmittelbare Problem.
Das eigentliche, unbequeme Problem löst es nicht.
Relay war eines der besten No-Code-Automatisierungs-Tools auf dem Markt. Einfach, durchdacht, ungewöhnlich gut bei KI-Integrationen – und hinter dem Tool steckte ein Team, das schnell lieferte.
Vor drei Monaten machte es noch vollständig Sinn, es zu nutzen.
Jetzt verschwindet es.
Die offensichtliche Lektion: Du solltest nicht zu stark von einer einzelnen Plattform abhängen.
Die größere Lektion, denke ich, ist unbequemer:
Die ursprüngliche Prämisse der No-Code-Automatisierung gilt nicht mehr.
Das hat nicht mit Relay begonnen
Anfang 2026 habe ich mir eine Herausforderung gesetzt: Hör auf, unsere internen Automatisierungen mit No-Code-Tools zu bauen.
Nicht weil sie plötzlich aufgehört hätten zu funktionieren.
Ich wollte verstehen, wie weit KI-gestützte Entwicklung wirklich gekommen ist.
Könnte jemand wie ich – kein Entwickler, aber jemand, der seine Karriere rund um Notion und No-Code-Automatisierung aufgebaut hat – die visuellen Workflow-Builder durch echten Code ersetzen?
Die Antwort war: Ja.
Nicht perfekt. Nicht magisch. Und definitiv nicht, indem ich Claude Code einmal öffne und tippe: „Bau mir mein Business-System.”
Aber konsistent genug, dass der alte Standard immer schwerer zu rechtfertigen schien.
Relay überlebte als gelegentliche Ausnahme, weil es für kleine Helfer wirklich schnell war. Ironischerweise war es oft schneller, etwas in Relay zu bauen als in n8n oder Make.
Für alles, was Teil unserer operativen Infrastruktur werden sollte, gewann Code jedoch bereits.
Dann kamen Notion Workers.
Während ich einen Workshop dazu vorbereitete, fragte ich mich immer wieder:
Warum würde ich einen Notion Worker nutzen, wenn ich das bereits in Make bauen kann?
Dann wurde mir klar: Ich hatte die Frage falsch gestellt.
Warum würde ich das in Make bauen, wenn KI mir helfen kann, echten Code zu schreiben?
Das war der Auslöser, dieses Prinzip auch in unsere Kundenarbeit zu übertragen.
Für neue Kunden-Infrastruktur ist Code jetzt unser Standard. No-Code nutzen wir noch gelegentlich für wegwerfbare oder wirklich schnellere kleine Helfer – aber nicht mehr als Fundament eines operativen Systems.
Relays Abschied hat diese Entscheidung nicht verursacht.
Er hat sie bestätigt.
Das Angebot, das No-Code-Automatisierung gemacht hat
No-Code-Automatisierungs-Tools haben uns ein unglaublich attraktives Angebot gemacht.
Du musstest weder APIs, OAuth, Cron-Jobs, Server, Deployment, Logging noch Error-Handling verstehen, um zwei Tools zu verbinden und stundenlange manuelle Arbeit zu eliminieren.
Du hast einen visuellen Builder geöffnet.
Deine Accounts verbunden.
Ein paar Module auf eine Canvas gezogen.
Und den Workflow fertiggestellt, bevor ein traditioneller Entwickler die Aufwandsschätzung fertig geschrieben hatte.
No-Code hat in drei Bereichen gewonnen:
- Zugang — Nicht-Entwickler konnten endlich selbst Integrationen bauen.
- Geschwindigkeit — Kleine Workflows ließen sich in Stunden statt Wochen umsetzen.
- Kosten — Das Automatisieren kleiner interner Prozesse wurde wirtschaftlich.
Der letzte Punkt war wichtiger, als die meisten erkannt haben.
No-Code hat nicht nur bestehende Software günstiger gemacht. Es hat verändert, was sich überhaupt zu bauen lohnte.
Das lästige wöchentliche Handoff wurde es wert, behoben zu werden.
Die 15-minütige Admin-Aufgabe wurde es wert, eliminiert zu werden.
Der kleine interne Workflow, den kein Engineering-Team jemals priorisieren würde, wurde möglich.
Ich habe einen großen Teil meiner Karriere auf dieser Veränderung aufgebaut.
No-Code hat mir als Nicht-Entwickler Zugang zu APIs, Automatisierung und Systemdenken gegeben. Es hat mir geholfen, Notion mit dem Rest des Tool-Stacks eines Unternehmens zu verbinden – und schließlich eine Beratung rund um diese Arbeit aufzubauen.
Ich spreche nicht von außen über etwas, das ich ablehne.
Ich argumentiere, dass die Leiter, auf der ich hochgeklettert bin, gerade ersetzt wird.
KI hat das ursprüngliche Wertangebot gebrochen
Die alte Alternative zu No-Code war individuelle Software.
Und individuelle Software bedeutete: Entwickler, Spezifikationen, Server, Deployments, lange Timelines und ein Budget, das für die meisten internen Workflows keinen Sinn ergab.
Dieser Vergleich machte den visuellen Canvas zum offensichtlichen Gewinner.
Aber das ist nicht mehr der Vergleich.
Heute kann ein Operator, der einen Workflow versteht, die Anforderungen einem KI-Coding-Agenten beschreiben, die Edge Cases prüfen und die erste Implementierung in weniger Zeit generieren lassen, als es dauert, durch einen komplexen No-Code-Canvas zu klicken.
Je komplexer der Workflow wird, desto stärker dieser Vorteil.
Eine Anforderung im Code zu ändern kann bedeuten: das neue Verhalten beschreiben und den Diff reviewen.
Eine Anforderung im visuellen Builder zu ändern kann bedeuten: zehn Module öffnen, Felder neu zuordnen und jeden Branch manuell prüfen.
No-Code hat Software einst zugänglich gemacht.
KI wird zur neuen Zugänglichkeitsschicht.
Das bedeutet nicht, dass zuverlässige Software plötzlich einfach wäre.
KI hat das Schreiben von Code dramatisch einfacher gemacht. Es hat nicht den Bedarf an Urteilsvermögen, Testing, Security, Monitoring, Wartung oder einem klaren Verständnis dessen, was das System tun soll, beseitigt.
Diese Unterscheidung ist wichtig.
Das Argument ist nicht, dass jeder an einem Freitagabend ein kritisches Business-System vibe-coden und dann vergessen kann.
Das Argument ist, dass das manuelle Zusammenklicken von Business-Logik in einem proprietären visuellen Canvas nicht mehr der effizienteste Weg ist, diese Logik auszudrücken.
Der visuelle Canvas kann das Produkt nicht mehr rechtfertigen
Hier stehen Make und n8n vor einem viel größeren Problem als dem Abgang eines Wettbewerbers.
Wenn sie nicht neu definieren, wofür ihre Produkte da sind, bewegt sich ihr aktuelles Visual-Building-Modell auf die Bedeutungslosigkeit zu.
Der Canvas kann nicht die primäre Authoring-Oberfläche bleiben.
Eine plausiblere Zukunft sieht anders aus:
- Du beschreibst den Workflow in natürlicher Sprache.
- Das System übersetzt diese Beschreibung in Code oder eine andere portierbare Darstellung.
- Der Canvas visualisiert den Prozess, Abhängigkeiten und Fehler.
- Die Plattform übernimmt Authentifizierung, Deployment, Retries, Logs und Monitoring.
- Menschen nutzen die visuelle Schicht, um das System zu verstehen und zu debuggen – nicht um jede Berechnung manuell zu konfigurieren.
In dieser Zukunft ist das wertvolle Produkt kein Drag-and-Drop-Code-Ersatz.
Es ist ein operativer Rahmen rund um Software, die KI beim Erstellen hilft.
Es gibt noch Dinge, die diese Plattformen bieten können.
Verwaltete Authentifizierung ist wertvoll. Zuverlässige Retries sind wertvoll. Governance und Observability sind wertvoll. Eine Bibliothek schwieriger API-Konnektoren ist wertvoll – insbesondere für geschlossene Plattformen, bei denen der Zugang selbst aufwändig zu implementieren ist.
Aber das sind sehr andere Gründe, das Produkt zu kaufen.
Das ursprüngliche Versprechen lautete: Du brauchst keinen Code.
Das nächste Versprechen muss möglicherweise lauten: Wir machen KI-generierten Code sicher und beherrschbar.
Das ist kein Feature-Update.
Es ist ein anderes Business.
Die dauerhafte Fähigkeit war nie das Wissen, wo man klickt
Wenn Du jahrelang Workflows in Relay, Make oder n8n gebaut hast, ist das kein Argument dafür, dass dein Wissen wertlos ist.
Ganz im Gegenteil.
Du hast bereits den größten Teil der konzeptuell schwierigen Arbeit gelernt:
- Was löst den Workflow aus?
- Welche Daten braucht er?
- Welches System besitzt diese Daten?
- Was passiert, wenn ein Feld fehlt?
- Welche Ausnahmen gibt es in der Business-Logik?
- Was soll passieren, wenn eine API ausfällt?
- Wer muss informiert werden, wenn etwas kaputtgeht?
Das ist Systemkompetenz.
Sie überträgt sich auf alle Tools.
Genau zu wissen, wo man auf einer Plattform klickt, tut das nicht.
Das dauerhaft Wertvolle war nie der Workflow-Canvas. Es war dein Verständnis des Prozesses, der darauf abgebildet wurde.
KI macht dieses Verständnis wertvoller, weil es Operatoren ermöglicht, es in einer flexibleren Form auszudrücken.
Die Person, die den Workflow versteht, kann jetzt viel näher dran sein, die Software zu bauen.
Die Person, die nur die Oberfläche versteht, hat ein Problem.
Was wir stattdessen bauen
Unsere neuen Kundensysteme haben in der Regel zwei Heimaten.
Wenn die Logik direkt in Notion leben soll, nutzen wir Notion Workers: kleine TypeScript-Programme, die von Notion gehostet werden und Webhooks empfangen, externe Daten synchronisieren oder zu Tools für Custom Agents werden können.
Für Infrastruktur, die mehr Kontrolle, länger laufende Prozesse oder Dienste außerhalb von Notions Grenzen braucht, deployen wir Custom Code auf verwalteter Hetzner-Infrastruktur.
Es gibt ein amüsantes Element des vollen Kreises dabei: Hetzner ist auch unser Kunde. Wir haben ihren Teams einmal geholfen, bessere operative Systeme in Notion aufzubauen; jetzt hilft ihre Infrastruktur uns, die nächste Generation von Systemen zu betreiben, die wir für andere Kunden bauen.
Der wichtige Punkt ist nicht, dass alle genau diesen Stack kopieren sollten.
Notion Workers sind nicht der neue Hammer, der jedes Problem wie einen Nagel aussehen lässt. Hetzner ist auch keine magische Antwort.
Der Punkt ist: Die Business-Logik ist nicht mehr in einem Automatisierungs-Canvas eingesperrt.
Wir können die richtige Laufzeitumgebung für die Aufgabe wählen.
Wir können die Implementierung in Versionskontrolle halten.
Wir können sie testen, dokumentieren, verschieben und KI bei der Wartung helfen lassen.
Das Tool wird zur Deployment-Entscheidung – nicht zur Fähigkeit selbst.
Also, ist No-Code-Automatisierung tot?
Nicht morgen.
Es wird eine Übergangsperiode geben. Bestehende Workflows werden weiter laufen. Teams werden Tools nutzen, die sie bereits kennen. Viele einfache Automatisierungen werden es nicht wert sein, neu zu bauen, nur weil ein neuerer Ansatz existiert.
Und einige No-Code-Unternehmen werden sich möglicherweise schnell genug neu erfinden, um zur KI-ersten operativen Schicht zu werden, die oben beschrieben wurde.
Aber die Ära der No-Code-Automatisierung als Standard-Zugangschicht für nicht-technische Builder geht zu Ende.
Ihre ursprünglichen Vorteile – Zugang, Geschwindigkeit und Kosten – werden durch KI-gestützte Entwicklung erodiert.
Die Plattformen mögen überleben.
Das alte Wertangebot wird es nicht.
Wenn Du ein Operator bist, lautet die Antwort nicht: in Panik verfallen und den nächsten Canvas wählen.
Lerne, Systeme klar zu beschreiben. Lerne, wie APIs, Authentifizierung und Fehlerbehandlung auf konzeptioneller Ebene funktionieren. Lerne, einen KI-Coding-Agenten zu führen, zu reviewen, was er produziert, und zu erkennen, wo die gefährlichen Stellen sind.
Du musst kein traditioneller Softwareentwickler werden.
Aber Du solltest jemand werden, der einen Workflow gut genug versteht, um ihn neu zu bauen, wenn sich die Plattformschicht ändert.
Denn Relay wird nicht das letzte Tool sein, das verschwindet.
Und Plattform-Kompetenz ist temporär.
Systemkompetenz wächst mit der Zeit.
Wenn Du diesen Wandel in einer konkreten Umgebung üben möchtest, beginne mit unserem vollständigen Einsteiger-Guide zu Notion Workers. Er führt Dich durch drei verschiedene Worker-Typen und lässt Dich echte Automatisierungen bauen, ohne den Code von Hand zu schreiben.
Wenn die Herausforderung nicht nur darin besteht, einen einzelnen Workflow zu bauen, sondern einem ganzen Team zu helfen zu verstehen, wo KI hingehört, deckt unser Notion AI Essentials Training die Frameworks, den gemeinsamen Kontext und die wiederverwendbaren Fähigkeiten hinter diesem Wandel ab.
Und wenn Du über isolierte Experimente hinausgehen und ein zuverlässiges Betriebssystem rund um Notion, KI und individuelle Infrastruktur aufbauen möchtest, ist genau das, was wir durch unsere Notion-Beratung tun.
