Low-Code oder Individualentwicklung: ohne Mehrkosten und technische Schulden wählen

Ein Unternehmen will ein Partnerportal starten, die Freigabe von Anträgen automatisieren oder schnell eine neue Dienstleistung testen. Es gibt zwei Wege. Der erste: in wenigen Wochen eine Lösung auf einer Low-Code-Plattform aus fertigen Bausteinen zusammensetzen. Der zweite: ein eigenes System entwerfen und volle Kontrolle über Logik, Daten und Oberfläche behalten.

Die Frage Low-Code oder Individualentwicklung wird oft als Kampf „billig gegen hochwertig“ geführt, doch das ist der falsche Rahmen. Low-Code ist kein günstiger Ersatz für Entwickler, und Individualentwicklung muss kein mehrjähriges Millionenprojekt sein. Es sind verschiedene Werkzeuge, und die Wahl hängt davon ab, wie kritisch der Prozess ist, welche Integrationen nötig sind und wie er sich in ein bis zwei Jahren verändert. Betrachten wir die Wahl anhand von drei typischen Aufgaben.

Die Kategorien in Kürze

Eine Low-Code-Plattform erlaubt es, Oberflächen und Prozesse aus fertigen Komponenten, visuellen Abläufen und Konnektoren zu bauen. Code schreibt man nur dort, wo die Standardfunktionen nicht reichen: Microsoft Power Apps, Retool, OutSystems, Mendix, für Prozessautomatisierung n8n, Make oder Zapier.

No-Code-Plattformen wie Bubble, Glide oder Airtable richten sich an Menschen ohne Programmierkenntnisse. Die Grenze ist fließend: Jede ernsthafte Lösung, auch mit der Maus zusammengeklickt, braucht dennoch Fachleute für Architektur, Sicherheit und Integrationen.

Aufgabe 1. Ein Partnerportal für 300 Händler

Partner sollen ihre Preise, Bestände, Bestellhistorie und Dokumente sehen. Die Daten liegen im ERP, der Zugriff erfolgt von außen, und jeder sieht nur die eigenen Informationen.

Low-Code deckt Oberfläche und Autorisierung hier in wenigen Wochen ab, stößt aber schnell an zwei Grenzen: Lizenzierung pro externem Nutzer und Limits bei der Zahl der ERP-Anfragen. Bei 300 Partnern können die Plattformkosten die Entwicklungskosten schon im zweiten Jahr übersteigen.

Praktisches Fazit: Nutzen Dutzende interne Personen das Portal, nehmen Sie Low-Code. Sind es Hunderte externe, rechnen Sie die Gesamtbetriebskosten über drei Jahre — oft gewinnt Individualentwicklung oder ein hybrider Ansatz mit eigenem Backend und Admin-Panel auf der Plattform.

Aufgabe 2. Interne Freigabe von Anträgen

Ein Beschaffungsantrag durchläuft drei Freigebende, hat ein SLA und eine Entscheidungshistorie. Hier ist Low-Code fast immer die richtige Antwort: Der Prozess ist typisch, die Nutzer sind intern, und die Integrationen beschränken sich auf E-Mail und das Mitarbeiterverzeichnis.

Das Risiko liegt woanders — im unkontrollierten Wildwuchs. Ein Jahr später gibt es vierzig Automatisierungen ohne Dokumentation, und die Person, die sie gebaut hat, ist weg. Deshalb braucht selbst ein einfacher Prozess einen Anwendungsverantwortlichen, ein Register der Integrationen und eine Rechteprüfung einmal pro Quartal.

Aufgabe 3. Ein Produktkonfigurator mit eigener Preislogik

Der Kunde wählt Parameter, das System berechnet den Preis nach komplexen Regeln, prüft Kompatibilität und reserviert Material. Das ist bereits ein Wettbewerbsvorteil des Unternehmens.

Hier ist Individualentwicklung gerechtfertigt: Die Logik lässt sich schwer in visuellen Blöcken abbilden, die Last ist ungleichmäßig, und den Kern des Geschäfts auf einer fremden Plattform zu halten ist riskant. Dasselbe gilt, wenn personenbezogene Kundendaten nicht bei einem Drittanbieter liegen dürfen oder die Oberfläche einzigartig sein muss.

Vergleich der Ansätze

Wie man die Kosten ehrlich rechnet

Der erste Prototyp auf Low-Code ist tatsächlich günstig, doch die Rechnung wächst unbemerkt. Nehmen Sie in die Dreijahresrechnung die Lizenzierung mit wachsender Nutzerzahl auf, kostenpflichtige Konnektoren, Limits für Operationen und Datensätze, separate Tarife für Testumgebungen, die Arbeit einer Support-Fachkraft und die Kosten eines möglichen Wechsels.

Bei Individualentwicklung gehören in dieselbe Tabelle Entwicklung, Hosting, Tests, Monitoring und Weiterentwicklung. Oft zeigt sich: Über ein Jahr ist Low-Code günstiger, über drei Jahre bereits die eigene Lösung. Genau deshalb entscheidet man nach TCO und nicht nach dem Startpreis.

Die Plattform vor dem Start prüfen

Klären Sie vor der Wahl einige Punkte: wie die Lizenzierung bei wachsender Nutzerzahl funktioniert, welche Limits API und Speicher haben, ob sich alle Daten in einem Standardformat exportieren lassen, ob es getrennte Umgebungen für Entwicklung und Test, Backups und ein Aktionsprotokoll gibt. Und vor allem: Wie sieht Ihr Ausstiegsplan aus, falls die Plattform teurer wird oder nicht mehr passt?

Microsoft hebt in den Empfehlungen zur Power Platform ausdrücklich Administratorrollen, die Trennung der Umgebungen, Sicherheit und Monitoring hervor. Diese Regeln bremsen die Arbeit nicht, bewahren aber ein Jahr später vor Chaos.

Der Hybrid ist meist die richtige Antwort

Low-Code und Individualentwicklung müssen keine Gegensätze sein. Ein verbreitetes Modell: Kritische Geschäftslogik und Daten liegen im eigenen Backend, während das interne Admin-Panel oder das Reporting per API darüber auf Low-Code entsteht. Ein anderes Szenario: Ein MVP auf der Plattform prüft die Hypothese, danach wandert der wertvollste Teil in ein eigenes Produkt.

Wichtig ist, die Grenzen vorab zu definieren. Eine Plattform darf nicht zum zufälligen Speicher kritischer Logik werden, die sich nicht migrieren lässt. Wie man den Moment erkennt, in dem eine Standardlösung nicht mehr genügt, beschreibt unser Artikel „Wenn der Onlineshop dem CMS entwachsen ist“ — die meisten Anzeichen gelten auch für interne Systeme. Geht es um E-Commerce mit mehreren Kanälen, gehört zusätzlich die Headless-Architektur in den Vergleich.

Fünf Fragen vor der Entscheidung

Wie einzigartig ist dieser Prozess für Ihr Unternehmen? Was passiert, wenn die Plattform einen Tag oder eine Woche nicht verfügbar ist? Welche Daten werden verarbeitet und dürfen sie bei einem Drittanbieter liegen? Wie viele Nutzer und Vorgänge erwarten Sie in einem Jahr? Welche Integrationen brauchen Sie und unterstützt die Plattform sie ab Werk?

Lauten die meisten Antworten „typisch, überschaubar, unterstützt“ — nehmen Sie Low-Code. Betreffen mindestens zwei Antworten Einzigartigkeit, Kritikalität oder Größenordnung, planen Sie Individualentwicklung oder einen Hybrid.

Häufige Fragen

Lässt sich ein System später von Low-Code auf Individualentwicklung umstellen?

Ja, aber fast immer bedeutet das einen Neuaufbau. Halten Sie deshalb Daten von Beginn an in einem exportierbaren Format und dokumentieren Sie die Prozesslogik.

Ist Low-Code sicher?

Große Plattformen schützen ihre Infrastruktur gut. Risiken entstehen nicht durch die Plattform, sondern durch unkontrollierte Zugriffsrechte, öffentliche Links und fehlende Protokolle.

Was ist über drei Jahre günstiger?

Für ein internes Werkzeug mit einigen Dutzend Nutzern meist Low-Code. Für ein System mit Hunderten externen Nutzern, komplexen Integrationen oder hoher Last ist die eigene Entwicklung oft wirtschaftlicher.

Wie lange dauert ein MVP auf Low-Code?

Ein typisches internes Werkzeug entsteht inklusive Integrationen in zwei bis sechs Wochen. Entscheidend ist, vorab festzulegen, woran Sie die Hypothese als bestätigt ansehen.

Ist der Prozess typisch und der Wert schnell zu prüfen, kann Low-Code der beste Start sein. Definiert das System das Produkt, hat es komplexe Integrationen oder hohe Risiken, gibt die eigene Architektur mehr Kontrolle. GL.ua kann ein Discovery durchführen, einen Prototyp bauen und bei der Wahl des Ansatzes helfen, ohne an ein Werkzeug gebunden zu sein — mehr zu unseren Leistungen in der Website- und Systementwicklung.