SOLUTIONS.designer

Anwendungen modellieren statt programmieren

Was im SOLUTIONS.designer entsteht, und was ein Generator daraus macht.

„Ohne Programmierung“ ist ein Versprechen, das jemand einlösen muss. Wir lösen es so ein: Sie beschreiben Ihre Anwendung in Bauteilen, die eine Maschine lesen kann, und eine Maschine baut sie. Kein Sprachmodell, das rät, sondern ein Generator, der Regeln befolgt.

Was „eine Anwendung modellieren“ konkret bedeutet

Fast jede Fachanwendung im Mittelstand hat dasselbe Gerüst. Es gibt Dinge, über die das Unternehmen Buch führt: Geräte, Verträge, Standorte, Prüftermine. Jedes hat Eigenschaften, eine Nummer, ein Datum, einen Status, einen Betrag. Und sie hängen aneinander: Der Vertrag gehört zum Kunden, das Gerät zu einem Standort.

Dieses Gerüst wird im SOLUTIONS.designer aufgeschrieben, nicht in Prosa, sondern in Datensätzen: eine Entität je Ding, ein Feld je Eigenschaft, eine Beziehung je Zusammenhang, dazu Formulare und Listen.

Der Unterschied zum Lastenheft ist der entscheidende. Ein Lastenheft darf lückenhaft und mehrdeutig sein, ohne dass es auffällt. Ein Modell darf das nicht: Ein Feld hat einen Typ oder keinen, eine Beziehung zeigt auf eine Entität oder ins Leere. Diese Härte ist unbequem, und der Grund für die wenigen Überraschungen danach.

Woraus ein Anwendungsmodell besteht

Die tatsächlichen Bauteile, jedes ein Datensatz, den Sie sehen und ändern.

Entität: das Ding, über das Buch geführt wird

Gerät, Mietvertrag, Standort, Prüftermin. Jede bekommt ein Leitfeld, das sie dort benennt, wo sie als Verweis auftaucht.

Feld: eine Eigenschaft mit Typ und Regeln

Sechzehn Typen, vom Text bis zum mehrsprachigen Feld. Dazu Pflichtangabe, Längen, Wertebereich, Nachkommastellen, Einheiten wie € oder kg, Prüfmuster, geprüft im Formular und im Backend.

Beziehung: wer hängt woran

Sechs Ausprägungen. Die Rückrichtung legt der Designer selbst an: Trägt der Vertrag ein Feld für seine Geräte, erscheint am Gerät das Gegenstück.

Auswahlliste und berechnetes Feld

Jeder Auswahlwert hat Beschriftung je Sprache, Farbe und Symbol, deshalb sieht derselbe Status überall gleich aus. Berechnete Felder füllt das System und zeigt sie gesperrt statt versteckt.

Formular, Liste, Menü, Erscheinungsbild

Abschnitte halten Eingabefelder im Raster, blenden die Liste einer verknüpften Entität ein oder betten ein zweites Formular ein. Zur Liste gehören Spalten, Sortierung, Suche und Filter.

417

Entitäten über 58 damit erzeugte Anwendungen

3.733

Felder, davon 1.066 Beziehungen

317 Auswahllisten, 199 berechnet

423 / 444

Formulare und Listen, jede mit Suche und Filter

420

Aufgaben, die sich nicht modellieren ließen

Aus unseren Repositories und dem eigenen Betrieb gezählt, Stand 12. August 2026.

Vom Modell zum lauffähigen Programm

Ist das Modell vollständig, läuft der Generator. Er liest die Datensätze und schreibt daraus ein gewöhnliches Projekt: ein Angular-Frontend, ein NestJS-Backend, ein MongoDB-Schema und die gemeinsamen Modellklassen. Was dabei herauskommt, ist Quelltext, den Sie lesen und mitnehmen können, kein Klick-Dummy und keine Laufzeitumgebung, die Ihre Konfiguration bei jedem Seitenaufruf neu auslegt.

Das entscheidet über den Ausstieg. Wo eine Plattform die Konfiguration zur Laufzeit ausführt, endet die Anwendung mit dem Vertrag. Bei uns läuft sie weiter, siehe Vendor-Lock-in bei Low-Code.

Was zwischen „fertig modelliert“ und „läuft“ passiert

Der Lauf dauert Minuten. Wichtiger ist, dass jeder Schritt festliegt.

Modell prüfen
Ein Prüflauf meldet Beziehungen ins Leere, Listen ohne Sortierfeld, Felder ohne Platz im Raster.
vor jeder Generierung
Datenmodell und Backend
Datenbankschema, NestJS-Bausteine für Lesen, Anlegen, Ändern und Löschen, die Serverprüfungen aus den Feldregeln, eine dokumentierte Schnittstelle.
Oberfläche
Angular-Komponenten samt Routen. Frontend und Backend teilen sich die Modellklassen. Ein umbenanntes Feld bleibt nirgends stehen.
Rahmenfunktionen einhängen
Anmeldung, Mehrsprachigkeit, Anhänge, Protokoll und die übrigen Zusatzfunktionen kommen aus dem Framework.
28 Funktionen als Schalter
Ausliefern
Ein Projekt im Git-Repository und ein Container-Abbild, betriebsbereit auf unserem Kubernetes-Cluster oder bei Ihnen.

Wie das Modell entsteht: von Hand oder im Gespräch

Screenshot SOLUTIONS.designer Drag And Drop Development

Von Hand oder im Gespräch, dasselbe Ziel

Der klassische Weg ist der Workshop: Wir gehen Ihren Prozess gemeinsam durch und modellieren dabei mit, also Entitäten anlegen, Felder ziehen, Beziehungen verbinden, Formulare im Raster anordnen. Dafür braucht es keinen Entwickler; der erste Entwurf entsteht bei uns durch Projektleitung oder Vertrieb, gemeinsam mit Ihnen.

Bei größeren Vorhaben nehmen wir jemand aus der Entwicklung mit in den Workshop. Nicht zum Modellieren — dafür reicht der Designer —, sondern für die Fragen, die daneben aufkommen: was die Schnittstelle zum ERP wirklich bedeutet, ob eine Regel sich konfigurieren lässt oder programmiert werden muss, was die Altdaten an Nacharbeit kosten. Angefangen wird das nicht mit einem Tagestermin, sondern mit einer kostenlosen Stunde per Videokonferenz.

Der zweite Weg ist neuer und beginnt bei Ihnen am Schreibtisch. Claudette, unsere Assistentin auf der Plattform Prompt Your App, führt das Anforderungsgespräch im Chat: Sie laden die Leistungsbeschreibung, das Fachkonzept oder die Excel-Tabelle von heute hoch, und daraus entsteht ein Modellentwurf mit Vorschau. Claudette legt die Datensätze selbst an, ohne eine Zeile Anwendungscode. Beide Wege enden an derselben Stelle, bei Datensätzen im Designer, in denen Sie jedes Feld sehen und ändern, was nicht passt. Und es geht auch ohne beides: Liegt ein Fachkonzept bereits vor, modelliert eine Person daraus unmittelbar. So ist zuletzt eine Mietgeräteverwaltung mit 13 Entitäten und 176 Feldern entstanden, aus der gerade ein Prototyp zur Vorstellung gebaut wird.

So arbeitet Claudette

Prompt Your App ausprobieren

Der Designer bleibt bei uns, das Ergebnis geht an Sie

Alle anderen Dienste dieser Reihe können Sie lizenzieren und wahlweise bei sich betreiben. Der SOLUTIONS.designer nicht. Er ist unser Arbeitsgerät, mit dem wir Ihre Anwendung bauen, und er wird nicht mit ausgeliefert. An Sie geht das Ergebnis: der erzeugte Quelltext in Ihrem Git-Repository und die Dokumentation, die aus dem Modell entsteht.

Es gibt einen zweiten Weg, und der ist ein Angebot an Ihre Fachabteilung. Auf der Plattform Prompt Your App lässt sich der Designer als SaaS-Lizenz mieten, betrieben bei uns, genutzt von Ihnen. Damit modellieren Ihre Leute selbst, und nicht nur die eine Anwendung, über die wir gerade sprechen, sondern so viele Konzepte, wie sie durchdenken wollen. Eine Idee sauber aufschreiben, sehen, wie groß sie wird, sie verwerfen oder weiterverfolgen. Was übrig bleibt, besprechen wir anschließend mit Ihnen, und es liegt dann bereits in der Form vor, in der wir es weiterbauen.

Was Sie gar nicht erst modellieren müssen

Der gemeinsame Unterbau

Anmeldung, Datenzugriff, Validierung, Mehrsprachigkeit und Protokollierung kommen aus dem SOLUTIONS Framework, siehe Aufbau einer Fachanwendung.

Fertige Fachdienste

Rollen und Rechte, Verzeichnisanbindung, E-Mail und Kennzahlen liegen außerhalb des Modells, in eigenen Diensten, etwa SOLUTIONS.user für Rollen und Rechte oder SOLUTIONS.connect_LDAP für die Anbindung an Ihren Verzeichnisdienst.

Zusatzfunktionen als Schalter

28 Funktionen werden je Anwendung eingeschaltet statt programmiert: Offline-Betrieb, Echtzeit-Aktualisierung, Aktivitätsprotokoll, Anhänge, Archivierung, mobile App. Welche davon zur Verfügung stehen, hängt an der Fassung der Basisbibliotheken: Von den hier genannten liegen vier allein in Enterprise. Die Merkmalsmatrix unter Lizenzmodell und Quellcode führt es Zeile für Zeile auf.

Dokumentation und Beispieldaten

Aus dem Modell entsteht eine Benutzerdokumentation als Baum: je Entität, Liste und Formular eine Seite. Dazu Beispieldaten für die Vorschau.

Warum erzeugter Code etwas anderes ist als geschriebener

Ein Sprachmodell erzeugt die statistisch plausibelste Fortsetzung. Bei Prosa fällt das mit „richtig“ meist zusammen, bei Software nicht. Der Veracode GenAI Code Security Report 2025 fand in 45 Prozent der geprüften Code-Samples Schwachstellen aus den OWASP Top 10, über die Modellgenerationen hinweg ohne Verbesserung. Im Benchmark BaxBench, vorgestellt auf der ICML 2025, waren unter 35 Prozent der Backends zugleich korrekt und sicher.

Ein Generator hat dieses Problem nicht, weil er nichts erfindet. Er kennt für jeden Feldtyp einen Weg, ihn darzustellen, zu prüfen und zu speichern. Der Preis ist Enge: Er kann nur, was einprogrammiert wurde. Der Gewinn ist Wiedererkennbarkeit: Wer eine unserer Anwendungen kennt, findet sich in der nächsten zurecht. Ausführlich: Kann KI eine App programmieren?

Wo das Modellieren aufhört

Handanpassungen werden nicht fortgeschrieben. Eigene Geschäftslogik gehört deshalb in getrennte Dateien, die an definierten Ereignissen einhaken, und in eigene Oberflächenkomponenten. Beides übersteht einen Generatorlauf. Ist eine Anwendung stark von Hand ausgebaut, wird sie irgendwann nicht mehr überschrieben, weil sich in gewachsenem Code nicht mehr zuverlässig jede Stelle richtig setzen lässt. Dafür liegt in jedem erzeugten Projekt der Modellstand mit, aus dem es entstanden ist. Der Designer vergleicht ihn mit dem neuen Stand und schreibt auf, was sich geändert hat und wo es einzubauen ist, Feld für Feld und Aufgabe für Aufgabe. Diese Liste ist für Menschen geschrieben und lässt sich ebenso einem Sprachmodell vorlegen. Deshalb hat Konfiguration Vorrang vor Programmierung.

Nicht jede Fachlogik lässt sich modellieren. Eine Preisstaffel mit Sonderregeln, eine Schnittstelle zu einem betagten Warenwirtschaftssystem, ein Prüfalgorithmus aus einer Norm. Das bleibt Programmierarbeit und wird als benannte Aufgabe geplant. Zu jedem Modellelement ist ein Erfahrungswert hinterlegt, also rechnet der Designer diesen Teil des Aufwands aus dem Modell heraus. Was sich nicht modellieren lässt, wird einzeln geschätzt und kommt als eigene Position dazu.

Die schwierige Frage bleibt beim Fachbereich. Die Oberfläche folgt einem Raster, keinem freien Zeichenbrett. Und welcher Prozess tatsächlich gelebt wird, beantwortet nur, wer die Arbeit kennt. Der Designer beschleunigt das Bauen, nicht das Entscheiden.

Weiterlesen

Häufige Fragen

Was heißt es, eine Anwendung zu modellieren statt sie zu programmieren?

Sie beschreiben, welche Dinge die Anwendung verwaltet, welche Eigenschaften diese haben, wie sie zusammenhängen und wie Masken und Listen aussehen. Ein Generator setzt das in ein Angular-Frontend, ein NestJS-Backend und ein Datenbankschema um. Sie schreiben keinen Quelltext, entscheiden aber fachlich alles.

Welche Feldtypen und Beziehungen kennt der SOLUTIONS.designer?

Sechzehn Feldtypen, darunter Text, Zahl, Datum, Ja/Nein, Auswahlliste, Beziehung, E-Mail, Passwort, Datei, mehrsprachiger Text und Verzeichnisbenutzer. Beziehungen gibt es in sechs Ausprägungen, von der einseitigen Zuordnung bis zur beidseitigen Mehrfachbeziehung. Zu jedem Feld gehören Regeln für Pflichtangabe, Längen, Wertebereiche und Prüfmuster.

Wie unterscheidet sich generierter Code von Code, den eine KI schreibt?

Ein Sprachmodell liefert bei derselben Anforderung zweimal ein anderes Ergebnis, ein regelbasierter Generator immer dasselbe. Der Veracode GenAI Code Security Report 2025 fand in 45 Prozent der KI-Code-Samples Schwachstellen aus den OWASP Top 10, ohne Verbesserung über die Modellgenerationen.

Kann ich den generierten Code selbst anpassen?

Ja, es ist ein gewöhnliches Angular-/NestJS-Projekt in Ihrem Git-Repository. Damit eine Änderung den nächsten Generatorlauf übersteht, gehört sie in eigene Dateien, die an definierten Ereignissen einhaken. Was sich gar nicht modellieren lässt, wird als geschätzte Aufgabe geplant statt übersprungen.

Bekomme ich neben der Webanwendung auch eine mobile App?

Auf Wunsch ja: Dieselbe Modellbeschreibung erzeugt zusätzlich eine Flutter-App. Der Umfang ist heute kleiner als im Browser: Datenmodelle, Zugriffsdienste, Listen- und Leseansichten. Mobile Eingabemasken sind Folgearbeit und werden eigens geplant.

Kann ich den SOLUTIONS.designer selbst lizenzieren?

Nicht wie unsere anderen Dienste. Der Designer bleibt unser Arbeitsgerät; an Sie geht der erzeugte Quelltext. Es gibt ihn aber als SaaS-Lizenz auf der Plattform Prompt Your App: Ihre Fachabteilungen modellieren damit selbst, beliebig viele Konzepte und nicht auf eine Anwendung beschränkt, und besprechen das Ergebnis anschließend mit uns.