Low-Code- und No-Code-ERP: Wo die Plattform an ihre Grenzen stößt

Zwischen „Standard kaufen” und „individuell bauen” hat sich eine dritte Stufe etabliert: Low-Code- und No-Code-Plattformen, mit denen man Anwendungen ohne klassische Programmierung zusammenklickt. Die aktuelle Welle KI-nativer ERP-Anbieter setzt genau darauf — ein Marktführer im Fertigungssegment führt „No-Code” sogar im Markennamen und unter seinem YouTube-Handle. Das wirft eine ehrliche Frage auf: starkes Werkzeug oder Falle? Die Antwort ist beides — je nachdem, wofür man es einsetzt. Für eng umrissene Abläufe ist No-Code stark. Als Fundament für ein geschäftskritisches ERP hat es zwei strukturelle Haken. Diesen Artikel schreiben wir aus der Perspektive von jemandem, der die Alternative baut — und der diese Stufe bewusst überspringt. Den breiteren Rahmen dazu spannt unser Leitfaden individuelle ERP-Software für den Mittelstand.

Wofür Low-/No-Code wirklich gut ist

Fangen wir fair an, denn der Reiz ist real. Für eng umrissene, unkritische Abläufe sind No-Code-Tools ein vernünftiges, oft das beste Werkzeug: ein Genehmigungs-Workflow, eine interne Checkliste, ein Dashboard, das ein paar Datenquellen zusammenzieht, ein schneller Prototyp, mit dem man eine Idee testet, bevor man Budget bindet. Solche Fälle sind klar begrenzt, ändern sich selten in der Tiefe und tragen kein Geschäftsrisiko, wenn sie mal ausfallen.

Der Vorteil ist echt: schnell aufgesetzt, günstig im Einstieg, keine Entwicklerstunden für etwas, das im Kern simpel ist. Wer eine Fachabteilung in die Lage versetzen will, ihren eigenen kleinen Ablauf zu digitalisieren, ohne dafür ein Projekt aufzusetzen, trifft mit No-Code häufig die richtige Wahl. Genau dafür sind diese Plattformen gebaut — und in diesem Rahmen liefern sie. Der Fehler beginnt nicht beim Werkzeug, sondern dort, wo man es zur tragenden Wand eines Systems macht, das den Betrieb am Laufen halten muss.

Haken 1: die Plattform-Decke

Der erste strukturelle Haken ist eine Decke, die man nicht sieht, bis man dagegen stößt. No-Code-Plattformen bilden das ab, was die Plattform vorgesehen hat. Solange der Anwendungsfall innerhalb dieses Rahmens bleibt, fühlt sich das grenzenlos an. Sobald aber die Logik komplexer wird, die Integration tiefer reichen muss oder das Datenvolumen wächst, stößt man an Grenzen, die man nicht selbst auflösen kann.

Das ist der entscheidende Unterschied zu individuell gebauter Software: Bei einer Plattform-Decke gibt es keinen Workaround, den man selbst baut. Man kann nicht „eine Ebene tiefer” gehen und das Problem lösen, weil diese Ebene dem Anbieter gehört. Man wartet auf dessen Roadmap, formuliert ein Feature-Request, oder man biegt den eigenen Prozess so lange, bis er wieder in den vorgesehenen Rahmen passt — also genau die Verbiegung, die man mit einer individuellen Lösung vermeiden wollte. „Konfigurierbar” ist nicht dasselbe wie „unbegrenzt”. Konfiguration bewegt sich immer innerhalb der Möglichkeiten, die jemand anderes vorab definiert hat. Für einen begrenzten Workflow reicht das. Für ein System, das genau dort stark sein soll, wo euer Betrieb anders ist als der Wettbewerb, ist diese Decke das Kernproblem — denn das Besondere liegt fast immer außerhalb des Vorgesehenen.

Haken 2: der Lock-in

Der zweite Haken folgt aus dem ersten. Die Anwendung, die ihr zusammenklickt, lebt nicht als eigenständige Software — sie lebt auf der Plattform des Anbieters. Ihr mietet eine Fähigkeit auf fremder Infrastruktur. Die Logik, die euer Geschäft abbildet, liegt in einem proprietären Format, das ohne diese Plattform nicht läuft.

Das macht den Ausstieg teuer bis unmöglich. Was bleibt, ist eine Konfiguration in einem proprietären System, nicht eine eigenständig lauffähige Anwendung. Eine Migration bedeutet in der Praxis nicht Umzug, sondern Neubau — die ganze Logik muss in einer anderen Umgebung von vorn entstehen. Damit verschiebt sich die Machtbalance dauerhaft zum Anbieter: Preisänderungen, Roadmap-Entscheidungen und Plattform-Strategie liegen außerhalb eurer Kontrolle, und der naheliegende Ausweg — wechseln — ist genau der, der versperrt ist.

Bemerkenswert ist, wer diesen Punkt zuerst nennt: Das Low-Code-Marketing selbst führt Lock-in regelmäßig als bekannten Nachteil auf. Das ist kein Vorwurf von der Custom-Seite, sondern eine offene Eigenschaft der Kategorie. Für einen unkritischen Ablauf ist dieser Lock-in ein akzeptabler Preis. Für das System, in dem eure Kalkulation, eure Auftragssteuerung und eure Kundenlogik stecken, ist er eine strategische Abhängigkeit an der empfindlichsten Stelle.

Der „Code ist nur ein winziger Teil”-Einwand

Es gibt einen starken Gegeneinwand, und er verdient eine faire Darstellung. Ein Anbieter KI-nativer ERP-Software (Bonx, „Buy vs. build your manufacturing ERP”, Rémi Bèges, 27.05.2026) argumentiert sinngemäß: Ein ERP über Code anzupassen, ist eben nicht nur das Schreiben des Codes. Man muss das System verstehen, die Änderungen der KI prüfen, sicher ausrollen, die Produktion gesund halten, Monitoring betreiben, Regressionen abfangen. Der eigentliche Code sei „nur ein winziger Teil der Arbeit” — und wer das selbst stemmt, mache aus seinen besten Leuten im Betrieb über die Zeit ein Wartungsteam.

Und das ist richtig. Für DIY und Vibe-Coding stimmt jeder Satz davon. Wenn ein Unternehmen ohne Engineering-Erfahrung anfängt, sein ERP per KI selbst umzubauen, landet es genau dort: bei ungeprüften Änderungen, unsicheren Deployments und einer schleichend wachsenden Wartungslast, die das eigentliche Geschäft auffrisst. Roher KI-Output ist eben nicht automatisch wartbar — eine kontrollierte METR-Studie (Juli 2025) fand, dass erfahrene Entwickler an ihren eigenen, reifen Codebasen mit KI sogar 19 Prozent langsamer waren und es nicht einmal merkten (METR ergänzte im Februar 2026, dass die Werkzeuge sich seither verbessert haben). Senior-Urteil ersetzt das nicht.

Nur: Genau deshalb baut man es nicht selbst. Der Einwand argumentiert gegen Amateure, die bauen — nicht gegen ein professionell gebautes System. Ein professioneller Builder bringt das mit, was DIY fehlt: Senior-Engineering, Coding-Agenten und die Disziplin aus Tests, Review und sauberen Deployments. Das Ergebnis ist wartbarer Code — und der Builder ist der Wartungspuffer, nicht der Kunde. Ihr werdet nicht zum Wartungsteam; ihr bekommt eines an die Seite gestellt. Wie diese Disziplin konkret aussieht, vertiefen wir in ERP mit KI-Coding-Agenten entwickeln.

Warum wir diese Stufe überspringen

kitun bietet die Low-/No-Code-Stufe bewusst nicht an — und zwar aus Effizienz, nicht aus Prinzipienreiterei. Die No-Code-Abkürzung existiert, weil echtes Bauen früher zu teuer und zu langsam war. Diese Annahme verschiebt sich. Mit Coding-Agenten, Senior-Architektur und einem eigenen Baukasten erprobter Standard-Komponenten bauen wir echte, wartbare Software schnell genug, dass die Abkürzung ihren eigentlichen Zweck verliert: Wenn das Ziel ohnehin in Wochen erreichbar ist, lohnt der Umweg über ein angemietetes Plattform-Konstrukt mit Decke und Lock-in nicht mehr. Und weil wir Bewährtes wiederverwenden, bekommt ihr ein zusammenhängendes System, das genau zu eurem Betrieb passt — nicht den nächsten Flicken.

Was ihr stattdessen bekommt, ist echte, eigenständige Software statt einer Plattform-Konfiguration: on-premise oder EU-gehostet möglich, ohne Plattform-Decke, ohne Abo und ohne Preis pro Nutzer. Keine fremde Roadmap, die über euren nächsten Prozessschritt entscheidet; kein proprietäres Format, aus dem ihr nicht mehr herauskommt. Dass das real und schnell geht, zeigt unsere SaaS-Plattform heysuma: als Greenfield bis zur Version 1.0 in drei Monaten gebaut — wartbar und produktionsreif, nicht zusammengeklickt. Wer die Kategorien direkt gegeneinander abwägen will, findet das in AI-natives ERP vs. individuelle Entwicklung; die zugrunde liegende Build-vs-Buy-Logik steht in Business und AI Agents: selbst entwickeln oder kaufen.

Häufige Fragen

Was sind die Nachteile von Low-Code-ERP? Zwei strukturelle: die Plattform-Decke und der Lock-in. Sobald Logik, Integrationstiefe oder Datenvolumen anspruchsvoll werden, stößt man an Grenzen, die man nicht selbst auflösen kann, sondern nur über die Roadmap des Anbieters. Und die Anwendung lebt auf dessen Plattform statt als eigenständige Software, was einen Wechsel teuer bis unmöglich macht. Für unkritische Abläufe sind diese Nachteile akzeptabel, für Geschäftskritisches selten.

Wo liegen die Grenzen von No-Code-ERP? Dort, wo der Anwendungsfall den vorgesehenen Rahmen verlässt — also genau bei dem, was euer Unternehmen vom Wettbewerb unterscheidet. „Konfigurierbar” heißt nicht „unbegrenzt”; Konfiguration bewegt sich immer innerhalb dessen, was die Plattform vorab definiert hat. Für eng umrissene Workflows reicht das, für ein differenzierendes Kernsystem ist es die Decke.

Wie schlimm ist der Lock-in bei Low-Code? Strukturell, nicht graduell. Es bleibt keine eigenständig lauffähige Anwendung, nur eine Konfiguration in einem fremden System. Eine Migration ist in der Praxis kein Umzug, sondern ein Neubau. Bemerkenswert: Das Low-Code-Marketing nennt diesen Lock-in selbst als bekannten Nachteil der Kategorie.

Ist es nicht klüger, ein ERP per No-Code zu nutzen, als es riskant selbst zu coden? Das ist ein berechtigter Einwand gegen DIY und Vibe-Coding — selbst gebaute ERP-Anpassungen ohne Engineering-Disziplin enden tatsächlich in Wartungschaos. Nur folgt daraus nicht No-Code, sondern: nicht selbst bauen. Ein professioneller Builder liefert wartbaren Code plus Übergabe und ist in der Zwischenzeit der Wartungspuffer. Ihr bekommt wartbare, eigenständige Software, ohne selbst das Wartungsteam zu sein.

Fazit

Low-Code und No-Code sind starke Werkzeuge — für eng umrissene, unkritische Abläufe. Als Fundament für ein geschäftskritisches ERP tragen sie zwei strukturelle Lasten: eine Plattform-Decke, die genau dort beginnt, wo euer Betrieb anders ist als der Wettbewerb, und einen Lock-in, der euch eine Konfiguration auf fremder Plattform statt eigenständiger Software hinterlässt. Der stärkste Gegeneinwand — Code sei nur ein winziger Teil der Arbeit — ist richtig, aber er spricht gegen das Selberbauen, nicht gegen das Bauenlassen. Wir überspringen diese Stufe nicht aus Dogma, sondern weil Coding-Agenten echtes, wartbares Bauen schnell genug machen, dass die Abkürzung ihren Sinn verliert. Was bleibt, ist ein System, das genau zu eurem Betrieb passt.

---

kitun ist eine AI-native Software-Manufaktur für den Mittelstand: Zwei Senior-Architekten und Coding-Agents bauen Custom Business-Software und ERP-Module — on-premise oder EU-gehostet, ohne Abo und ohne Lizenz pro Nutzer. Im 20-minütigen Erstgespräch klären wir ehrlich, welcher Weg für euren Fall der richtige ist.

→ Die Lösung im Überblick: Custom ERP mit kitun

→ Der ganze Leitfaden: Individuelle ERP-Software für den Mittelstand