Ich stecke gerade in einem kleinen Dilemma mit meinem aktuellen Projekt. Eigentlich habe ich mit einem No-Code-Tool angefangen, um schnell einen Prototypen für eine interne Verwaltungs-App zu bauen. Das hat auch super funktioniert, aber jetzt kommen immer mehr spezifische Anfragen vom Team, die das Tool einfach nicht kann. Ich frage mich, ob ich an dem Punkt bin, an dem ich die Plattform wechseln und einen hybriden Ansatz wählen sollte, also Low-Code mit etwas manuellem Code für die speziellen Logiken. Irgendwie fühlt sich das an, als würde ich die Grenzen des rein visuellen Builders ausreizen. Hat jemand ähnliche Erfahrungen gemacht, als die Anforderungen gewachsen sind?
Ich kenne das Dilemma gut. Der Prototyp lief im No Code Rahmen prima, doch mit immer mehr individuellen Anfragen stößt das visuelle Tool an seine Grenzen. Ein hybrider Weg klingt sinnvoll wenn klar definiert ist welche Logik wirklich handgeschrieben gehört und wie Datenaustausch funktioniert. Wichtig ist eine saubere Trennung von Prozesslogik und Benutzeroberfläche und regelmäßige Anpassung der Architektur.
Aus technischer Sicht macht der Gedanke an Low Code mit manuellem Code Sinn. Standardprozesse bleiben im Builder, Speziallogik kommt in kleine Module und gut dokumentierte Schnittstellen sorgen für Wartbarkeit. Ohne klare Architektur Kriterien driftet es sonst in Chaos ab, also vorher eine grobe Architektur entwerfen und dann schrittweise migrieren.
Ich bleibe skeptisch über die Versprechung hybrider Ansätze. Wenn die Anforderungen zu individuell sind lohnt sich vielleicht eine komplette Neuausrichtung der Plattform statt Patchwork. Das kostet Zeit und Geld und verändert die Arbeitsweise des Teams. Wie groß ist der Hebel wirklich?
Aber ich hab die Erfahrung gemacht dass man manchmal missversteht was der Aufbau bewirken soll. Der Gedanke an eine neue Technik kann sich als leichter Druck statt echte Lösung anfühlen. Vielleicht ist ein kompaktes kleines Feature zuerst dran und danach schaut man weiter.
Manche Leser erwarten klare Anweisungen doch hier ist eher ein Versuch den Prozess zu erkennen. Der Fokus könnte auch auf Governance liegen und darauf wie Entscheidungen dokumentiert werden. Es geht auch um das Vertrauen in das Team und die Bereitschaft Fehler zu machen.
Vielleicht lohnt es sich den Blick neu zu rahmen. Statt zu fragen ob No Code oder Low Code gewinnt man eher darüber nach wie Regeln für Änderungen entstehen und wer sie überwacht. Was zählt als kritisch bei der nächsten Iteration und wie misst man Erfolg?
