Low-Code vs. traditionelle Entwicklung: Wann konfigurieren und wann programmieren in Creatio

Die eigentliche Frage im Jahr 2026 lautet selten „Low-Code oder Code“. Es geht vielmehr darum, welche Teile einer Lösung auf einer Plattform konfiguriert werden sollten und welche Teile eine kundenspezifische Entwicklung verdienen. Dieser Leitfaden bietet einen praktischen Rahmen, basierend darauf, wie wir die Arbeit an Creatio-Projekten aufteilen.

Von Grygoriy Synieok, CEO & Gründer von SYNTECH · 8 Min. Lesezeit

Zwei Ansätze, zwei unterschiedliche Aufgaben

Low-Code (und No-Code) bedeutet, Anwendungen durch die Konfiguration einer Plattform zu erstellen: Datenmodelle, Seiten, Geschäftsregeln und Prozesse werden in visuellen Designern zusammengestellt. In Creatio sind das der Freedom UI Designer, der Prozessdesigner (BPMN) und die No-Code-Tools für Objekte, Nachschlagewerke und Dashboards.

Traditionelle Entwicklung bedeutet, die Anwendung selbst zu schreiben: Architektur, Datenschicht, APIs, UI, Sicherheit, Hosting und Wartung.

Beide sind legitim. Sie lösen unterschiedliche Probleme, und die meisten fehlgeschlagenen Projekte, die wir sehen, haben einen Ansatz für alles gewählt.

Wo Low-Code eindeutig gewinnt

Low-Code ist die bessere Standardwahl, wenn die Lösung prozesszentriert ist und sich häufig ändert:

CRM und Kundenoperationen – Vertriebspipelines, Servicefälle, Marketing.
Back-Office-Workflows – Genehmigungen, Dokumentenfluss, Anfragen, Onboarding.
Betriebssysteme rund um einen Geschäftsprozess – Projektmanagement, Personalwesen, Logistikverfolgung, Produktionsaufträge.
Portale und interne Apps, die auf denselben Daten basieren.

Warum es in diesen Bereichen gewinnt:

Änderungen sind kostengünstig. Geschäftsregeln, Phasen und Felder ändern sich jedes Quartal. Auf einer Plattform ändert ein Analyst oder No-Code-Ersteller diese ohne einen Release-Zyklus.
Plattformfunktionen sind kostenlos. Zugriffsrechte, Audit, mobile App, Benachrichtigungen, Suche, Dashboards und Integrationen müssen nicht erstellt werden.
Das Unternehmen kann die Lösung lesen. Ein BPMN-Prozess in einem Designer ist eine Dokumentation, die aktuell bleibt.
Upgrades sind die Aufgabe des Anbieters. Sicherheitspatches und neue Funktionen kommen mit Plattform-Updates.

Wo traditionelle Entwicklung die richtige Wahl ist

Kundenspezifische Entwicklung ist gerechtfertigt, wenn der Kern des Produkts Technologie und nicht Prozess ist:

Hochlast- oder Echtzeitsysteme, bei denen Sie die Leistung auf jeder Ebene kontrollieren müssen.
Komplexe Algorithmen – Optimierungs-Engines, Preismodelle, aufwendige Berechnungen.
Einzigartige, kundenorientierte UX, die selbst das Produkt ist.
Mobile-First-Verbraucherprodukte mit offline-lastigem, gerätespezifischem Verhalten.
Tiefe Hardware- oder Protokollintegration außerhalb von Standard-APIs.

Wenn ein System auf Code-Ebene ein Wettbewerbsvorteil ist, lohnt sich der Aufwand für den Besitz des Codes in der Regel.

Das hybride Modell: Code innerhalb der Plattform

Die nützlichste Erkenntnis aus Creatio-Projekten ist, dass „Low-Code vs. Code“ innerhalb einer modernen Plattform eine falsche Wahl ist. Creatio ist standardmäßig konfiguriert, verfügt aber über klar definierte Erweiterungspunkte für die Entwicklung:

In der Praxis bedeutet dies:

Konfigurieren Sie 80–90% der Lösung – die Teile, die das Unternehmen ständig ändern wird.
Programmieren Sie die verbleibenden Ränder – eine komplexe Berechnung, eine Integration mit hohem Volumen, eine spezialisierte visuelle Komponente.
Verpacken Sie wiederholten Code als wiederverwendbare Komponenten. Zum Beispiel begannen unsere Gantt-, Kanban- und Pivot-Ansichten für Creatio als benutzerdefinierte Angular-Komponenten und wurden zu konfigurierbaren Anwendungen, die No-Code-Ersteller ohne Code-Schreiben einrichten können.

Das oben genannte Verhältnis ist unsere Arbeitsrichtlinie, keine universelle Statistik. Der Punkt ist, dass der Entwicklungsaufwand dort konzentriert wird, wo er Wert schafft.

Kosten: Betrachten Sie die Gesamtbetriebskosten, nicht die erste Veröffentlichung

Der Vergleich nur des initialen Builds ist irreführend. Ein fairer Vergleich über 3–5 Jahre beinhaltet:

Bei prozesslastigen Anwendungen dominieren Änderungsanfragen und Wartung in der Regel die Gesamtkosten, weshalb Plattformen dort tendenziell gewinnen. Für einen stabilen algorithmischen Kern, der sich selten ändert, kann kundenspezifischer Code auf lange Sicht günstiger sein.

Eine Entscheidungs-Checkliste

Beantworten Sie diese Fragen für jeden Teil der Lösung:

Wie oft wird sich die Logik ändern? Monatliche oder vierteljährliche Änderungen bevorzugen die Konfiguration.
Ist es eine Standardgeschäftsfunktion (CRM, Genehmigungen, Aufgaben) oder ein einzigartiges Unterscheidungsmerkmal?
Was sind die Leistungsanforderungen? Typische geschäftliche Nutzung passt gut zu Plattformen; extremer Durchsatz oder Echtzeitverarbeitung möglicherweise nicht.
Wer wird es in zwei Jahren warten – Analysten und No-Code-Ersteller oder ein dediziertes Entwicklungsteam?
Verfügt die Plattform bereits über eine Komponente oder eine Marketplace-App dafür? Prüfen Sie dies, bevor Sie etwas entwickeln.
Kann der benutzerdefinierte Teil hinter einer API oder einer Komponente isoliert werden, sodass der Rest konfigurierbar bleibt?

Wenn die meisten Antworten auf „ändert sich oft, Standardfunktion, geschäftlich gewartet“ hindeuten, konfigurieren Sie es. Wenn ein bestimmter Teil einzigartig, leistungsentscheidend oder algorithmisch ist, entwickeln Sie diesen Teil und integrieren Sie ihn.

Häufige Fehler

Kundenspezifische Programmierung dessen, was die Plattform bereits leistet – zum Beispiel der Aufbau einer separaten Genehmigungs-Engine neben Creatio-Geschäftsprozessen.
Alles in die Konfiguration zwingen – Hunderte verschachtelter Regeln, wo ein kleiner, getesteter C#-Dienst klarer wäre.
Keine Architekturverantwortung. Hybride Lösungen benötigen jemanden, der entscheidet, wohin jede Anforderung gehört.
Upgrades ignorieren. Kundenspezifischer Code, der Plattform-APIs umgeht, bricht bei Updates; verwenden Sie unterstützte Erweiterungspunkte.

Zusammenfassung

Wählen Sie Low-Code für prozesszentrierte, sich häufig ändernde Geschäftsanwendungen. Wählen Sie die traditionelle Entwicklung für technologiezentrierte Produkte mit einzigartigen Leistungs-, Algorithmus- oder UX-Anforderungen. Kombinieren Sie beides in Creatio: Konfigurieren Sie die Prozesse und verwenden Sie Code nur an den Rändern, verpackt als wartbare Komponenten.

FAQ

Ist Low-Code nur für kleine Projekte geeignet?

Nein. Unternehmensplattformen wie Creatio betreiben große, abteilungsübergreifende Lösungen. Die Grenze ist nicht die Projektgröße, sondern die Art der Anforderung: prozesszentrierte Logik passt gut, extreme Leistung oder einzigartige Algorithmen können kundenspezifischen Code erfordern.

Können wir mit Low-Code beginnen und später kundenspezifischen Code hinzufügen?

Ja, wenn die Plattform unterstützte Erweiterungspunkte hat. In Creatio sind dies C#-Webdienste, Skriptaufgaben und benutzerdefinierte Freedom UI-Komponenten.

Führt die Verwendung von kundenspezifischem Code auf einer Plattform zu Problemen bei Upgrades?

Nicht, wenn er unterstützte APIs und Erweiterungsmechanismen verwendet. Probleme treten auf, wenn Code interne Plattformelemente direkt modifiziert.

Wer sollte entscheiden, was konfiguriert und was programmiert werden soll?

Ein Lösungsarchitekt, der sowohl die Plattform als auch die Geschäftsanforderungen kennt, in Zusammenarbeit mit dem Prozesseigner.

Sind Sie sich unsicher, wo die Grenze für Ihr Projekt liegt? Buchen Sie eine 30-minütige Beratung und wir prüfen Ihre Anforderungen und schlagen eine Aufteilung vor.

Verwandt: No-Code oder kundenspezifische Entwicklung: Was sollten Unternehmen im Jahr 2026 wählen? · No-Code CRM: Warum B2B-Unternehmen Creatio wählen · Creatio UI-Komponenten