Dies ist das Bedenken, das die meisten Menschen daran hindert, überhaupt zu beginnen – und es beruht auf einer falschen Annahme: dass Ihre Beschreibung direkt in Code umgesetzt würde, ohne Möglichkeit zur Korrektur. So läuft es aber nicht ab. Ihre Beschreibung erzeugt zunächst einen PLAN – eine Liste der Daten, Bildschirme und deren Typen – der Ihnen angezeigt wird und den Sie KORRIGIEREN, BEVOR auch nur eine einzige Codezeile existiert: benennen Sie eine Entität um, ändern Sie den Namen eines Feldes, fügen Sie einen Statuswert hinzu oder entfernen Sie ihn – oder passen Sie sogar den Typ eines Bildschirms an. Zu diesem Zeitpunkt kostet ein Fehler nichts. Nach der Generierung bleibt eine Änderung zwar weiterhin möglich, indem Sie die gewünschte Anpassung einfach auf Deutsch beschreiben – doch dann wird die gesamte Anwendung neu erstellt und erneut automatisch validiert: Das ist kein feiner Feinschliff, sondern ein tieferer Eingriff.
Der befürchtete Fehler ist nicht der, der tatsächlich auftritt
Die Sorge ist, eine unpräzise Beschreibung abzugeben und ein Werkzeug zu erhalten, das am Ziel vorbeigeht – ohne Möglichkeit zur Korrektur. Bei klassischen Projekten ist diese Sorge durchaus berechtigt: Das Lastenheft geht an einen Dienstleister, der erste Bildschirm erscheint Wochen später – und die Abweichung zahlt man in Entwicklungstagen. Es ist diese Verzögerung – nicht die Schwierigkeit des Formulierens, die die Aufgabe so belastend macht.
Die Fachliteratur zur Formulierung des Bedarfs sagt übrigens dasselbe – nur aus einem anderen Blickwinkel: Die Herausforderung liegt nicht darin, etwas schriftlich festzuhalten, sondern darin, zu wissen, was man will, bevor man überhaupt etwas gesehen hat. Man errät seine eigenen Arbeitsabläufe nicht – man erkennt sie, sobald sie konkret vor einem liegen.
Der Plan wird vor dem Code angezeigt – und ist bearbeitbar
Zwischen Ihrer Beschreibung und der fertigen Anwendung liegt eine Zwischenstufe: der Plan. Er listet die Daten auf, die das Werkzeug verwalten soll, ihre Felder sowie die Bildschirme mit ihrem jeweilIGEN TYP – etwa eine Tabelle, ein Kalender, ein Dashboard oder eine Karte. Dieser Plan wird Ihnen angezeigt und lässt sich bearbeiten.
Konkret können Sie zu diesem Zeitpunkt eine Entität und ihr Label umbenennen, die enthaltenen Felder korrigieren, Werte in einer Statusliste hinzufügen oder entfernen („In Bearbeitung“, „Genehmigt“, „Storniert“), einen Bildschirm umbenennen, sein Symbol ändern – oder sogar seinen Typ anpassen: Eine Liste, die eigentlich ein Kalender sein sollte, korrigieren Sie hier in einem Schritt.
Genau dieser Moment macht den Einwand obsolet. Eine grobe Beschreibung verpflichtet Sie zu nichts: Sie liefert lediglich einen Vorschlag, den Sie prüfen. Und ein Wort im Plan zu korrigieren ist genauso effektiv, als hätten Sie es beim ersten Mal richtig formuliert.
Nach der Generierung: immer noch möglich – aber kein leichter Handgriff mehr
Sobald die Anwendung erstellt ist, formulieren Sie Änderungen weiterhin auf Deutsch – etwa „Füge ein Feld für das Follow-up-Datum hinzu“ oder „Trenne Angebote von Rechnungen“. Der Unterschied liegt woanders: Diese Anfrage regeneriert den Plan, baut die Anwendung neu auf und führt sie erneut durch die automatische Validierung, bevor sie wieder in Betrieb genommen wird. Das Verfahren ist zuverlässig – aber nicht sofort verfügbar.
Daraus ergibt sich der einzige praktische Rat auf dieser Seite: Nehmen Sie sich fünf Minuten Zeit, um den Plan wirklich gründlich zu prüfen. Das sind die fünf kostengünstigsten Minuten Ihres gesamten Projekts.
Was Sie besser vor einer Änderung an einer bereits produktiven Anwendung wissen sollten
Zwei Punkte lassen sich nicht intuitiv erschließen – und sollten daher unbedingt geklärt werden, bevor Sie eine Änderung an einem Werkzeug vornehmen, das bereits Ihre echten Daten enthält.
Erster Punkt: Was geschieht mit bereits eingegebenen Daten, wenn sich die Struktur ändert – etwa bei Wegfall eines Feldes oder Aufteilung einer Entität in zwei separate Entitäten? Darauf gebe ich hier keine pauschale Antwort – das ist eine Frage, die Sie explizit stellen sollten, bevor Sie eine Live-Anwendung modifizieren, egal ob bei uns oder bei jedem anderen Anbieter.
Zweiter Punkt: Es gibt keinen Knopf „Zurück zur vorherigen Version“. Ein Rollback muss vorbereitet werden – es lässt sich nicht improvisieren. Daher lohnt es sich, Ihre Daten vor einer strukturellen Änderung zu exportieren – was der Bereich Einstellungen in den Formaten CSV und JSON ermöglicht.