Eine App mit KI zu bauen hat die Notwendigkeit, Code zu schreiben, beseitigt — nicht aber die Notwendigkeit, klar zu denken. Der Flaschenhals hat sich nur verschoben: Statt Syntax zu tippen, schreibst du jetzt ein Briefing. Ein vager Prompt erzeugt eine vage App — generische Screens, erfundene Funktionen, übersehene Randfälle — während ein präziser Prompt dem, was du wirklich wolltest, schon beim ersten Versuch erstaunlich nahekommt. Dieser Leitfaden zeigt, was ein guter App-Bau-Prompt wirklich enthält, stellt schlechte und gute Beispiele nebeneinander und erklärt, wie du iterierst, ohne kaputt zu machen, was schon funktioniert.
Die Anatomie eines guten App-Bau-Prompts
Stell dir deinen Prompt als Briefing vor, das du einem freiberuflichen Entwickler geben würdest, der dich nie getroffen hat und vor dem Start keine Rückfrage stellen kann. Je mehr der folgenden Punkte er selbst beantwortet, desto weniger muss die KI raten — und desto weniger musst du später korrigieren.
- Kontext — wer und was: für wen die App gedacht ist und welches Problem sie löst, in ein bis zwei Sätzen.
- Ziel: die eine Hauptsache, die jemand tun können muss — eine Dienstleistung verkaufen, Projekte verfolgen, eine Warteliste verwalten.
- Nutzer: wer sie tatsächlich benutzt — eine Einzelperson, ein kleines internes Team, externe Kunden, oder mehrere Rollen mit unterschiedlichem Zugriff.
- Wichtigste Screens: die vier bis sechs wichtigsten Seiten, explizit benannt — Dashboard, Kundenliste, Rechnungsdetail, Einstellungen.
- Datenentitäten: die "Substantive" deiner App und wie sie zusammenhängen — ein Kunde hat mehrere Projekte, ein Projekt hat mehrere Rechnungen.
- Rahmenbedingungen: alles, was nicht verhandelbar ist — Login erforderlich, Zahlungen, Mobile-First, eine bestimmte Integration.
- Ton und Marke: das gewünschte Erscheinungsbild — Farben, Stilreferenzen, formell oder verspielt.
Ein schlechter Prompt vs. ein guter Prompt
Der Unterschied zwischen einer mittelmäßigen App und einer wirklich nützlichen liegt fast nie am KI-Modell — es ist fast immer der Prompt. Hier ist derselbe Gedanke, zweimal geschrieben.
Schlechter Prompt: "Bau mir eine App, um meine Kunden zu verwalten."
Dieser Satz hat keinen Kontext, keine definierten Screens, kein Datenmodell und keine Rahmenbedingungen. Die KI muss alles erfinden, und was sie erfindet, wird kaum dem entsprechen, was du dir wirklich vorgestellt hast — generische Felder, ein erfundener Workflow, keine Ahnung, ob du allein oder im Team arbeitest.
Guter Prompt: "Ich leite eine kleine Design-Agentur mit zwei weiteren Freelancern. Bau mir ein Kundenportal, in dem wir alle unsere Kunden, die zu jedem gehörenden Projekte und die Rechnungen zu jedem Projekt sehen können. Ich brauche ein Dashboard mit den aktiven Projekten, eine Kundenliste mit Kontaktdaten, und eine Projektseite mit Aufgaben und Rechnungen samt Status (Entwurf, versendet, bezahlt). Kunden sollen sich einloggen können und nur ihre eigenen Projekte und Rechnungen sehen — nicht die Daten anderer Kunden. Halte das Design klar und minimalistisch, in Blau und Weiß."
Diese Version liefert den Kontext (eine Design-Agentur, drei Nutzer), das Ziel (Kunden, Projekte und Rechnungen zentralisieren), die Datenentitäten und ihre Beziehungen (Kunde → Projekt → Rechnung), die wichtigsten Screens, eine echte Rahmenbedingung (rollenbasierter Zugriff, damit jeder Kunde nur seine eigenen Daten sieht) und einen Ton (klar, minimalistisch, Blau und Weiß). Der KI bleibt fast nichts mehr zu erraten.
Fang breit an, dann verfeinere Screen für Screen
Der Versuch, jeden Screen, jedes Feld und jede Regel in einem einzigen riesigen Prompt zu beschreiben, geht meist schief: Die KI muss zu viel gleichzeitig im Blick halten, und etwas geht verloren oder wird nur halb umgesetzt. Ein besserer Rhythmus ist, mit einem breiten Prompt zu starten, der die gesamte Grundstruktur der App festlegt — die Entitäten, die Hauptscreens, die Navigation — und dann Screen für Screen weiterzugehen, wobei du jeweils ein Element verfeinerst.
- Erster Prompt: beschreibe den Zweck der App, ihre Nutzer und die Handvoll benötigter Screens, damit die KI das Grundgerüst bauen kann.
- Zweite Runde: wähle einen Screen und gehe tiefer — "füge in der Kundenliste eine Suchleiste und einen Statusfilter hinzu."
- Dritte Runde: gehe zum nächsten Screen über, sobald der vorherige stimmt, statt zwischen mehreren gleichzeitig zu springen.
Das spiegelt wider, wie ein echtes Produkt entsteht: zuerst ein solides Grundgerüst, dann Tiefe, die Funktion für Funktion, Screen für Screen hinzugefügt wird — nie alles auf einmal.
Neu prompten vs. Mikro-Anpassungen
Nicht jede Anfrage sollte gleich formuliert werden. Eine strukturelle Änderung — eine ganz neue Entität hinzufügen, die Navigation umgestalten, die Beziehung zwischen zwei Screens ändern — verdient einen neuen, ausführlicheren Prompt, der den Kontext für diesen Teil der App erneut erklärt. Eine kleine, überschaubare Änderung — ein Label umbenennen, eine Farbe anpassen, eine Liste anders sortieren — lässt sich besser als kurze Chat-Nachricht behandeln, die genau das gewünschte Ergebnis beschreibt.
- Neu prompten, wenn: du dem Datenmodell ein neues Konzept hinzufügst, Screens zusammenführst oder aufteilst, oder änderst, wie Rollen und Berechtigungen funktionieren.
- Mikro-Anpassung, wenn: du Formulierungen, Styling, Reihenfolge oder ein einzelnes Feld auf einem bestehenden Screen anpasst.
- Auch bei Mikro-Anpassungen: benenne den Screen und das genaue Element — "ändere auf der Rechnungsdetailseite das 'Bezahlt'-Badge auf Grün" ist deutlich sicherer als "mach es hübscher".
Häufige Fehler, die deine Prompts sabotieren
- Zu vage sein. "Mach es modern und professionell" gibt der KI nichts Konkretes zum Handeln — beschreibe, was modern und professionell für dich bedeutet: eine Referenzseite, eine Farbe, ein Layout.
- Zu viele Funktionen auf einmal verlangen. Ein Prompt, der Authentifizierung, Zahlungen, ein Dashboard und ein Benachrichtigungssystem gleichzeitig abdeckt, zwingt die KI, ihre Aufmerksamkeit auf alles zu verteilen.
- Implementierung statt Ergebnis beschreiben. "Verwende einen useEffect, um die Daten zu holen und in einem Reducer zu speichern" erklärt, wie programmiert werden soll, aber nicht, was der Screen für den Nutzer eigentlich tun soll — beschreibe das gewünschte Ergebnis, nicht die Technik.
- Randfälle vergessen. Was passiert bei einer leeren Liste, einer fehlgeschlagenen Zahlung, einem Kunden ohne Projekte? Sie von Anfang an zu benennen, erspart später eine ganze Runde Debugging.
Tipps für Vibe Coding mit einem AI App Builder
- Benenne den Screen, über den du sprichst. "Auf dem Dashboard" oder "auf der Einstellungsseite" beseitigt jede Unklarheit darüber, wo eine Änderung greift.
- Gib echte Beispiele. Statt "füge eine Preistabelle hinzu" füge die tatsächlichen Plannamen und Preise ein, die angezeigt werden sollen.
- Ändere beim Verfeinern jeweils nur eine Sache. Es ist viel leichter zu erkennen, was funktioniert hat, wenn ein Prompt eine einzige klare Absicht hat.
- Teste früh mit echten Daten. Ein Screen, der mit drei Beispielzeilen perfekt aussieht, kann bei fünfzig echten Zeilen zusammenbrechen — prüfe das so früh wie möglich.
- Sag, was gleich bleiben soll. Wenn du einen Screen verfeinerst, erwähne, dass der Rest der App unverändert bleiben soll.
Dieselbe Anatomie funktioniert für Showcase-Seiten, Web-Apps und Mobile
Das Grundgerüst aus Kontext, Ziel, Nutzern, Screens, Daten und Rahmenbedingungen ändert sich nicht danach, was du baust — nur die Gewichtung verändert sich. Bei einer Showcase-Seite legst du mehr Gewicht auf Ton, Marke und die Texte jedes Abschnitts (Hero, Leistungen, Referenzen, Kontakt). Bei einer Web-App legst du mehr Gewicht auf die Datenentitäten und ihre Beziehungen, weil genau das langfristig tragen muss. Bei einer Mobile-App fügst du Rahmenbedingungen zu Navigationsmustern, Offline-Verhalten und dem Gefühl auf einem kleinen Bildschirm hinzu. Derselbe klare, strukturierte Prompt richtet sich einfach auf eine andere Art von Produkt.
Wie Cadrant hilft
Cadrant basiert darauf, in natürlicher Sprache zu beschreiben, was du willst, und es im Gespräch zu verfeinern. Du beginnst mit einem breiten Prompt, der deine App beschreibt — ihren Zweck, ihre Nutzer und die wichtigsten Screens — und Cadrant erzeugt eine funktionierende erste Version. Von dort aus iterierst du per Chat, Screen für Screen, genau wie es dieser Leitfaden empfiehlt: eine gezielte Nachricht, um eine Funktion hinzuzufügen, eine kurze, um ein Detail anzupassen, eine ausführlichere, wenn du etwas Neues ins Datenmodell einführst.
Derselbe Workflow in natürlicher Sprache gilt egal, ob du eine Showcase-Website, eine vollständige Web-App mit Authentifizierung und Datenbank oder eine Mobile-App baust — du beschreibst das Ergebnis, Cadrant übernimmt die Umsetzung, und du verfeinerst weiter, bis jeder Screen dem entspricht, was du im Kopf hattest.