Ich stecke gerade in einem kleinen Dilemma mit meinem aktuellen Projekt. Ich habe eine interne Tool-Idee mit einem No-Code-Builder umgesetzt, die im Kern eigentlich ganz gut funktioniert. Jetzt kommen aber ständig neue Feature-Wünsche vom Team, die das Tool an seine Grenzen bringen. Ich frage mich, ob ich mit meinem Ansatz an die Grenzen der No-Code-Entwicklung stoße und ab wann man vielleicht doch ein paar Zeilen Code schreiben sollte, auch wenn ich das eigentlich vermeiden wollte.
Boah, dieses ständige Nachbessern frisst mir die Zeit weg. Der No Code Entwicklung Ansatz hat zwar eine glatte Oberfläche, aber jedes neue Feature fühlt sich an wie Flickwerk am Rand des Baukastens.
Bevor man weiter baut sollte man eine Grenzsicht definieren. Welche Stabilität Wartbarkeit und Security braucht die No Code Entwicklung wirklich. Wenn neue Features den Architekturkuchen zu schwer machen ist vielleicht eine API Bridge oder ein kleines Code Modul sinnvoll.
(Dieser Beitrag wurde zuletzt bearbeitet: 01-28-2026, 08:33 PM von Avery98.)
Ich glaube du missverstehst die Idee Ein Builder soll doch in erster Linie Ideen testen und nicht den ganzen Betrieb tragen oder sehe ich das falsch?
Sollte man überhaupt Zeilen Code schreiben oder lassen sich alle Wünsche durch Integrationen lösen?
Das riecht nach Selbstbetrug No Code Entwicklung ist bequem doch echte Grenzen zeigen sich erst wenn Druck kommt.
Vielleicht geht es weniger um cleveren code gegen no code sondern um Governance UX und klare Abnahmekriterien Wenn der Fokus darauf liegt lassen sich Wünsche besser priorisieren.
Man könnte sich eine hybride Architektur vorstellen ein schlanker Kern in Code daneben die Oberfläche No Code Entwicklung und dazu Gedankenspiele über Module statt Regeln
