# App mit KI erstellen: Vom Prompt zum testbaren Prototyp Mit KI lässt sich eine App-Idee schnell sichtbar machen. Der Artikel führt vom klaren Problem über Daten und Kernablauf bis zum getesteten Prototyp und zeigt, was vor einem produktiven Einsatz zusätzlich nötig ist. Eine App mit KI zu erstellen beginnt heute oft mit einem Satz. Du beschreibst eine Idee, und ein Werkzeug erzeugt Oberfläche, Datenfelder und erste Funktionen. Der schnelle Fortschritt ist hilfreich, verführt aber zu einem falschen Schluss: Eine klickbare Demo ist noch keine Software, die echte Daten und Nutzer zuverlässig tragen kann. Der beste Einsatz liegt deshalb am Anfang eines Vorhabens. Mit einem kleinen Prototyp kannst du prüfen, ob der Ablauf verständlich ist und ob das Problem eine eigene Anwendung rechtfertigt. ## Entscheide zuerst, welche Art App du brauchst "App" kann vieles bedeuten: eine mobile Anwendung aus dem App Store, eine Web-App im Browser, ein internes Werkzeug oder einen Wegwerfprototyp. Diese Formen unterscheiden sich bei Verteilung, Offline-Nutzung, Gerätefunktionen und Betrieb. Für viele B2B-Ideen ist eine Web-App der einfachste Test. Sie lässt sich über einen Link öffnen und ohne App-Store aktualisieren. Wenn Kamera, Standort, Push-Nachrichten oder starke Offline-Nutzung zentral sind, kann eine native mobile App später sinnvoll werden. Der Vergleich [Web-App, Mobile-App oder PWA](/de/wissen/web-app-mobile-app-oder-pwa) hilft bei dieser Entscheidung. ## Ein Problem statt einer Produktvision beschreiben Ein Prompt wie "Baue eine moderne App für Handwerksbetriebe" lässt zu viel offen. Das Werkzeug erfindet Rollen, Funktionen und Abläufe. Das Ergebnis sieht vollständig aus, basiert aber auf Annahmen, die niemand geprüft hat. Beginne enger: > Servicetechniker erfassen nach einem Einsatz Fotos, Material und eine kurze Notiz. Heute gehen Angaben in Chats verloren. Der Prototyp soll einen Einsatz anzeigen, die drei Angaben erfassen und eine Zusammenfassung zur Prüfung erzeugen. Damit sind Nutzer, Situation, heutiges Problem und gewünschter Kernablauf benannt. Alles Weitere bleibt vorerst draussen. ## Den Kernablauf in Zustände zerlegen Beschreibe nicht nur Bildschirme. Beschreibe, was vor und nach einer Handlung gilt. 1. Ein offener Einsatz ist einer Person zugewiesen. 2. Die Person öffnet den Einsatz. 3. Sie ergänzt Bilder, Material und Notiz. 4. Die App prüft Pflichtangaben. 5. Die Person sieht eine Zusammenfassung. 6. Erst nach Bestätigung gilt der Einsatz als abgeschlossen. Ergänze Fehlerfälle: Was geschieht ohne Netz? Was passiert bei einem zu grossen Bild? Darf ein abgeschlossener Einsatz verändert werden? Wer sieht welche Kundendaten? Diese Fragen wirken technisch, sind aber Produktfragen. Wenn sie offenbleiben, trifft der Generator die Entscheidung für dich. ## Mit Testdaten arbeiten Verwende in der ersten Version erfundene Namen, Adressen und Aufträge. Zugangsdaten, Kundendateien und interne Dokumente gehören nicht ungeprüft in ein externes Werkzeug. Testdaten sollten trotzdem realistisch sein. Nutze lange Namen, fehlende Werte, ungewöhnliche Zeichen und mehrere Rollen. Ein Prototyp, der nur mit drei perfekten Beispielen funktioniert, sagt wenig über den späteren Alltag aus. ## In kleinen Schritten prompten Lass zuerst den normalen Ablauf erstellen. Prüfe ihn, bevor du Anmeldung, Benachrichtigungen, Exporte und Integrationen ergänzt. Ein brauchbarer Auftrag für die erste Stufe enthält: - Ziel und Nutzerrolle - erlaubte Funktionen - bewusst ausgeschlossene Funktionen - benötigte Datenfelder - Regeln und Fehlermeldungen - gewünschte Darstellung auf Telefon und Desktop - Testfälle, die erfüllt sein müssen Bitte nach jeder Änderung um eine kurze Liste der veränderten Dateien und des neuen Verhaltens. Sichere funktionierende Zwischenstände. Wenn eine Änderung etwas anderes kaputtmacht, brauchst du einen Weg zurück. ## Sichtbares Verhalten testen Klicke nicht nur den vorgesehenen Weg durch. Versuche, ein Pflichtfeld leer zu lassen, denselben Vorgang zweimal auszuführen oder eine fremde URL direkt zu öffnen. Prüfe lange Texte, leere Listen und fehlerhafte Dateien. Beobachte auch andere Personen beim Test. Erkläre ihnen die Bedienung nicht vorab. Wenn sie einen Schritt nicht finden, ist das eine Erkenntnis über den Entwurf und nicht über die testende Person. Notiere nach jedem Test: - Was wollte die Person tun? - Wo hat sie gezögert oder abgebrochen? - Welche Annahme wurde bestätigt oder widerlegt? - Welche kleinste Änderung soll als Nächstes geprüft werden? ## Was ein Prototyp noch nicht beweist Ein funktionierender Prototyp beantwortet Fragen zu Ablauf und Verständlichkeit. Er beweist nicht automatisch: - dass Berechtigungen sicher sind - dass Daten korrekt gesichert werden - dass mehrere Personen gleichzeitig arbeiten können - dass Updates ohne Datenverlust möglich sind - dass Abhängigkeiten gepflegt werden - dass die Anwendung rechtliche Vorgaben erfüllt - dass jemand Fehler im Betrieb beheben kann Gerade KI-generierter Code kann plausibel aussehen und trotzdem schwer wartbar sein. Eine professionelle Prüfung betrachtet Architektur, Datenmodell, Zugriffe, Tests, Deployment und Betrieb. Die Unterschiede zwischen Experiment und tragfähigem Produkt beschreibt [Was ist Vibe Coding?](/de/wissen/was-ist-vibe-coding). ## Datenmodell und Rechte früh sichtbar machen Auch ein kleiner Prototyp profitiert von einer einfachen Liste seiner Datenobjekte. Im Beispiel wären das Einsatz, Kunde, Person, Materialeintrag und Anhang. Schreibe dazu, wer ein Objekt sehen, erstellen, ändern und löschen darf. Diese Tabelle verhindert viele spätere Missverständnisse: | Objekt | Lesen | Ändern | Löschen | |---|---|---|---| | Einsatz | zugewiesene Person, Disposition | vor Abschluss zuständige Person | nur Administration | | Kundendaten | zugewiesene Person | Disposition | nur Administration | | Anhang | Beteiligte am Einsatz | Ersteller bis Abschluss | Administration | Das konkrete Modell hängt von deinem Fall ab. Entscheidend ist, dass Rechte nicht erst nach der Oberfläche diskutiert werden. ## Wann du den Prototyp wegwerfen solltest Wegwerfen ist kein Scheitern. Ein Prototyp hat seinen Zweck erfüllt, wenn du etwas gelernt hast. Ein Neubau ist oft sinnvoll, wenn der Generator ohne klare Struktur viele Abhängigkeiten angelegt hat, niemand den Code versteht oder zentrale Anforderungen erst spät hinzugekommen sind. Manchmal lässt sich die erste Version sauber weiterentwickeln. Dafür braucht es eine Prüfung durch jemanden, der die technische Verantwortung übernehmen kann. Der Entscheid sollte vor dem öffentlichen Start fallen, nicht nach dem ersten Zwischenfall. ## Übergabe an ein Produktteam Dokumentiere Problem, Zielgruppe, getesteten Ablauf, offene Annahmen und Ergebnisse. Sichere Screenshots oder eine zugängliche Demo. Eine lange Funktionsliste ist weniger nützlich als fünf beobachtete Testläufe mit klaren Erkenntnissen. Im Workshop [App mit KI erstellen](/de/workshops/app-mit-ki-erstellen) setzt du diesen Ablauf praktisch um. Wenn aus dem Prototyp ein dauerhaftes B2B-Produkt werden soll, hilft ein [digitales Produktteam](/de/leistungen/saas-produktentwicklung) bei Scope, technischer Prüfung und Betrieb.