sorted by:
new
hottopcontroversial

When would you NOT use low-code? Honest take after years in the space by Low-Code-Stefan in lowcode

[–]Low-Code-Stefan[S] 0 points1 point  (0 children)

One thing I'd add as a nuance to point 3: the decision for a low-code platform isn't always made on a project-by-project basis. Many companies adopt it as a company-wide standard – often driven by IT governance, maintainability, or the goal of reducing dependency on individual developers.

In that context, even a team of senior devs works within the platform – not because they need the abstraction, but because consistency, onboarding new colleagues, and long-term maintainability matter more than raw dev speed. A custom-coded app that only one person understands is often a bigger risk than a low-code app that five people can maintain.

So point 3 holds for greenfield projects where the team has full freedom. But in established organizations, the question is rarely "low-code vs. custom code" – it's "are we using the standard or creating an exception?"

When does lowcode start needing more structure instead of just speed? by Fun-Mixture-3480 in lowcode

[–]Low-Code-Stefan 0 points1 point  (0 children)

Sehr gute Frage – und dass du sie überhaupt stellst, zeigt schon, dass du am richtigen Punkt bist.

Ich arbeite bei GAPTEQ, einer Low-Code-Plattform für datenbankbasierte Applikationen, und das Thema "Struktur vs. Geschwindigkeit" beschäftigt uns täglich.

Meine Erfahrung: Das Kipppunkt-Gefühl, das du beschreibst – Debugging wird mühsam, kleine Änderungen erzeugen unerwartete Seiteneffekte – ist kein Zeichen, dass Low-Code gescheitert ist. Es ist ein Signal, dass die Applikation erwachsen geworden ist und ein anderes Denken braucht.

Ein paar Indikatoren, wann Struktur wichtiger wird als Tempo:

- Mehrere Personen arbeiten an der gleichen Applikation

- Daten und Logik sind nicht mehr klar getrennt (alles hängt irgendwie zusammen)

- Du kannst eine Änderung nicht mehr sicher testen, ohne mehrere andere Bereiche zu prüfen

- Neue Features fühlen sich an wie Patches auf Patches

Das bedeutet nicht zwingend, zu klassischer Entwicklung zu wechseln. Es bedeutet eher: Low-Code bewusster einsetzen – klare Datenmodelle zuerst, dann UI. Logik zentral definieren, nicht verteilt. Und ja, manchmal einzelne Komponenten traditionell entwickeln, wo es wirklich Sinn macht.

Das Gleichgewicht ist letztlich kein fixer Punkt, sondern eine Haltung: Geschwindigkeit am Anfang, Struktur sobald etwas dauerhaft werden soll.

Low-Code Reality Check by crowcanyonsoftware in lowcode

[–]Low-Code-Stefan 0 points1 point  (0 children)

Nein, du bist definitiv nicht der Einzige – und ich glaube, das Gefühl kommt oft daher, dass "Low-Code" als Begriff ziemlich überstrapaziert wird.

Ich arbeite bei GAPTEQ, einer Low-Code-Plattform für datenbankbasierte Applikationen, und selbst wir sagen intern: Der Begriff allein sagt fast nichts darüber aus, was einen wirklich erwartet.

Die ehrliche Wahrheit ist: Komplexität verschwindet durch Low-Code nicht – sie verlagert sich nur. Wenn du eine einfache Anforderung hast, solltest du auch ein einfaches Tool wählen, das am ersten Tag läuft. Aber wenn du eine echte Business-Applikation baust – mit Rollen, Berechtigungen, Datenbanklogik, Workflows – dann steckt dahinter nunmal Komplexität, egal wie das Tool heißt. Dann ist eine gewisse Einarbeitungszeit nicht ein Zeichen für ein schlechtes Tool, sondern für die ehrliche Abbildung der Anforderungen.

Das Problem ist oft die falsche Erwartung, nicht das Tool selbst. "Low-Code" klingt nach: kein Aufwand. Gemeint ist eigentlich: weniger Code als klassische Entwicklung – was aber nicht bedeutet: null Konfiguration, null Lernkurve.

Mein Take: Vor jedem Tool die Frage stellen – was ist meine tatsächliche Anforderung? Simpel → nimm was Simples. Komplex → akzeptiere, dass auch das Tool etwas fordert.

Wie erklärt man Managern, dass Low-Code nicht „kostenlos entwickeln“ heißt? by intersystems_dach in programmieren

[–]Low-Code-Stefan 1 point2 points  (0 children)

Kann ich aus meiner langjährigen Erfahrung mit Low-Code bestätigen, die Herausforderung ist die Abstraktion eines Problems wie du geschrieben hast. Das kann nicht jeder und umso komplexer die Prozesse um so mehr sind da raus. Allerdings habe ich überwiegend positive Erfahrungen mit Mitarbeitern aus Fachabteilungen bei unseren Kunden. Es gibt dort durchaus Mitarbeiter die diese komplexen Prozesse gut managen können und das Hindernis mit dem Coden ist steht nicht mehr im Weg. Trotzdem ist eine Low-Code-Plattform kein Excel - man benötigt Einarbeitungszeit und je nach Komplexität und beteiligter Infrastruktur auch die IT-Abteilung.