Wie man eine App plant, bevor man promptet: Eine Pre-Build-Checkliste

TL;DR: Die meisten KI-gebauten Apps, die scheitern, wurden schlecht geplant, nicht schlecht gebaut. Die Pre-Build-Checkliste für Indie-Gründer: Zielnutzer (eine konkrete Person), Problemstellung (was sie aktuell tun, das schmerzt), Datenmodell (welche Entitäten und Beziehungen), Integrationen (welche externen Dienste), Erfolgskriterien (wie „gut“ aussieht), MVP-Umfang (was ausgeliefert werden muss vs. verschoben wird), Constraints (Zeitplan, Budget, Technik). 1–3 Stunden Planung vor dem Prompten sparen Tage, in denen das Falsche gebaut wird. Dieser Guide behandelt die vollständige Checkliste, die Deliverables (PRD, Datenmodell, Wireframes) und die Pre-Build-Disziplin, die ausgelieferte Apps von aufgegebenen Prototypen unterscheidet.

Einleitung

KI-App-Builder haben die Bauphase schnell gemacht. Ein Wochenende produziert, wofür früher Monate nötig waren. Der Flaschenhals hat sich stromaufwärts verschoben — die meisten gescheiterten KI-gebauten Apps scheitern, weil sie die falsche App waren, nicht weil sie schlecht gebaut wurden. Baugeschwindigkeit ohne Plandisziplin erzeugt schnelles Scheitern, nicht schnellen Erfolg.

Die Plandisziplin, die reife Produktteams über Jahrzehnte entwickelt haben, gilt weiterhin. Mit Nutzern sprechen; das Problem verstehen; die Lösung designen; das MVP spezifizieren; überlegt bauen. KI-App-Builder haben die Bauphase komprimiert; sie haben die Planungsphase nicht abgeschafft. Gründer, die die Planung überspringen und direkt ins Prompten einsteigen, produzieren oft technisch funktionierende Apps, die keine echten Probleme für echte Nutzer lösen.

Dieser Guide behandelt die realistische Pre-Build-Checkliste für Indie-Gründer, die KI-App-Builder nutzen. Die Fragen, die zu beantworten sind, bevor ein einziger Prompt geschrieben wird. Die Deliverables (PRD, Datenmodell, Wireframes). Die 1–3 Stunden Arbeit, die Tage sparen, in denen das Falsche gebaut wird.

Warum Planung im KI-Zeitalter weiterhin zählt

• Baugeschwindigkeit ohne Planung = schnelles Scheitern, nicht schneller Erfolg
• KI generiert, was man verlangt; ist die Anfrage falsch, ist der Bau falsch
• Die meisten KI-gebauten Apps, die scheitern, wurden schlecht geplant, nicht schlecht gebaut
• Planung dauert Stunden; Neubau dauert Tage
• Planung deckt Annahmen auf, bevor sie in Code gegossen werden
• Planung erzwingt Klarheit über Nutzer, Problem und Erfolg

Die Pre-Build-Checkliste

1. Zielnutzer (eine konkrete Person, nicht „alle“)

• Eine konkrete Person benennen, für die diese App ist
• Was ist ihr Job?
• Was ist ihr Kontext (Branche, Firmengröße, Rolle)?
• Welche Tools nutzen sie aktuell dafür?
• Wie hoch ist ihr technisches Komfortlevel?
• Zahlen sie aktuell für Tools in diesem Bereich? Wie viel?
• Spezifisch statt generisch — „Solo-Anwälte mit 1–3-Personen-Kanzleien“ schlägt „Fachkräfte“

2. Problemstellung

• Was macht der Nutzer aktuell, das schmerzt?
• Wie viel Zeit kostet es?
• Was läuft beim aktuellen Ansatz schief?
• Was kostet der aktuelle Schmerz (Geld, Zeit, verpasste Gelegenheit)?
• Wie dringend ist die Lösung für den Nutzer?
• Warum jetzt? Was hat sich geändert, sodass die Lösung wichtig wird?
• Vage Problemstellungen vermeiden — „zu viel Reibung“ ist bedeutungslos; „verbringt 4 Stunden/Woche mit manueller Eingabe von Rechnungsdaten in die Buchhaltungssoftware“ ist konkret

3. Datenmodell

• Welche Entitäten existieren in dieser App? (User, Projekt, Task, Rechnung usw.)
• Welche Attribute hat jede Entität?
• Welche Beziehungen bestehen zwischen den Entitäten? (User hat viele Projekte; Projekt hat viele Tasks)
• Was muss persistent sein vs. flüchtig?
• Was muss privat sein vs. geteilt?
• Das auf Papier skizzieren, bevor man promptet — spart erhebliches Refactoring
• Beispiel für einen Habit-Tracker: User → hat viele → Habit → hat viele → HabitLog (einer pro Tag pro Habit)

4. Integrationen

• Mit welchen externen Diensten verbindet sich diese App?
• Auth-Provider (Supabase, Clerk, Auth0 usw.)
• Zahlungsdienstleister (Stripe, Paddle, Lemon Squeezy)
• E-Mail-Dienst (Resend, Postmark, SendGrid)
• KI-APIs (OpenAI, Claude usw.), falls vorhanden
• Andere SaaS-APIs (Google Calendar, Slack usw.)
• Datenimport-Quellen (CSV, bestehende Tools)
• Integrationskosten identifizieren (manche sind Pay-per-Use)

5. Erfolgskriterien

• Woran erkennt man, ob diese App funktioniert?
• Quantitative Kennzahlen: Signups, Aktivierungen, Retention, Umsatz
• Qualitative Signale: Nutzer sagen „dafür würde ich zahlen“; Nutzer nutzen es wiederholt
• Konkrete Zahlen definieren — „10 Nutzer nutzen es täglich innerhalb von 30 Tagen nach Launch“
• Was würde die weitere Investition rechtfertigen? Was würde zum Stopp führen?
• Ausfallkriterien — wenn Metrik X bis Datum Z unter Y liegt, würde man umdenken

6. MVP-Umfang

• Was MUSS in V1 ausgeliefert werden, um überhaupt nützlich zu sein?
• Welche Features können aus V1 gestrichen werden?
• Die meisten Gründer packen zu viel in V1; aggressives Streichen gewinnt
• Test: Wenn Feature X entfernt würde, würden Nutzer dies für das Kernproblem trotzdem nützlich finden?
• Explizite „im Umfang“- und „außerhalb des Umfangs“-Listen definieren
• Alles verschieben, was das Kernproblem nicht löst

7. Constraints

• Zeitplan — Wann muss das ausgeliefert werden?
• Budget — Hosting, Tooling, bezahlte Dienste
• Technische Fähigkeiten — Was kann man selbst? Wofür braucht man Hilfe?
• Zeitaufwand — Wie viele Stunden pro Woche?
• Rechtlich/regulatorisch — branchenspezifische Einschränkungen (Gesundheitswesen, Finanzen usw.)
• Constraints informieren die Trade-offs während des gesamten Baus

Die Deliverables (was vor dem Prompten entsteht)

1. Ein-Seiten-PRD (Product Requirements Document)

• Titel und kurze Zusammenfassung (2–3 Sätze)
• Zielnutzer (konkret)
• Problemstellung
• Vorgeschlagene Lösung (die App selbst)
• Kernfeatures (max. 5–10)
• Was NICHT enthalten ist (explizite Non-Goals)
• Erfolgskriterien
• Constraints
• Maximal 1–2 Seiten

2. Datenmodell-Skizze

• Handgezeichnetes oder textbasiertes Entity-Relationship-Diagramm
• Jede Entität mit aufgelisteten Kernattributen
• Beziehungen zwischen Entitäten markiert
• Was RLS-geschützt ist (Datenisolation pro Nutzer)
• Was öffentlich vs. privat ist
• 30–60 Minuten Arbeit

3. Wireframes (optional, aber empfohlen)

• Grobe Skizzen von 3–5 Kernbildschirmen
• Handgezeichnet ist völlig ausreichend; Tools wie Excalidraw oder Figma optional
• Fokus auf Bildschirm-Flow, nicht pixelgenaues Design
• Hilft, die User Experience vor dem Prompten zu visualisieren
• 30–60 Minuten Arbeit

4. Der eigentliche Prompt

• Aufgebaut aus PRD, Datenmodell und Wireframes
• Detailliert genug, um das Richtige zu generieren
• Spezifiziert den Stack (Next.js, Supabase, Stripe usw.)
• Verweist explizit auf das Datenmodell
• Enthält Erfolgskriterien für den Bau selbst
• Spart deutlich Iteration gegenüber vagen Prompts

Beispiel-Pre-Build für einen Habit-Tracker

Zielnutzer

Erwachsene in Suchtgenesung, die AA, NA oder ähnliche 12-Schritte-Programme nutzen. Speziell jene, die 1–3 Jahre clean sind und tägliche Recovery-Gewohnheiten tracken wollen (Meeting-Teilnahme, Sponsor-Anrufe, Meditation, Journaling, Dankbarkeitspraxis). Nutzen aktuell einen Mix aus Papier-Journalen, generischen Habit-Apps und AA-Workbooks.

Problemstellung

Generische Habit-Tracker passen nicht zu Recovery-Workflows. Sie verstehen die Sprache nicht („einen Schritt bearbeiten“, „Sponsor-Check-in“, „Meeting-Teilnahme“). Sie nutzen schambasierte Streak-Mechaniken, die Nutzer in Recovery triggern. Sie verbinden Habits nicht mit Recovery-Zielen oder Schrittarbeit. Nutzer wechseln aktuell zwischen Papier, Streaks und dem BigBook ohne Integration.

Datenmodell

User (id, email, recovery_date, program) → hat viele → RecoveryHabit (id, user_id, name, target_frequency, category — Meeting/Step/Service/Daily) → hat viele → HabitLog (id, habit_id, date, completed, notes). SponsorContact (id, user_id, name, phone). MeetingLog (id, user_id, date, meeting_name, type). Alle Entitäten RLS-geschützt — Nutzer sehen nur ihre eigenen Daten.

Integrationen

Supabase Auth, Stripe ($4,99/Monat nach 14-tägiger kostenloser Testphase), Resend für E-Mails, optional Google Calendar für Meeting-Erinnerungen.

Erfolgskriterien

20 Nutzer, die mindestens 30 Tage lang tägliche Check-ins abschließen, innerhalb von 60 Tagen nach Launch. Durchschnittliche Zahlungsbereitschaft von $5/Monat, bestätigt durch 20+ Nutzerinterviews. Wenn der MRR nicht innerhalb von 90 Tagen nach Launch bei $500+ liegt, Richtung überdenken.

MVP-Umfang

• Drin: Habit-Definitionen, tägliche Check-ins, Streak-Tracking (ohne Scham-Mechaniken), Meeting-Log, Sponsor-Kontakt, einfache Analytics
• Draußen: KI-Features, Sharing/Social, Gruppen-Accountability, Integration mit AA-Servicearbeit, native Mobile-App

Pre-Build-Kundenrecherche (oft übersprungen, immer wertvoll)

• Vor dem Bau mit 10–15 potenziellen Nutzern der Zielgruppe sprechen
• Ihnen das PRD oder die Wireframes zeigen; fragen, ob sie das nutzen würden
• Fragen, was sie aktuell für das Problem tun, das man lösen will
• Fragen, was sie zahlen würden
• Fragen, was ihnen am wichtigsten ist
• Kundeninterviews decken falsche Annahmen auf
• Sparen den kompletten Bau des falschen Produkts

Häufige Fehler bei der Pre-Build-Planung

• „Alle“ als Zielgruppe — Generische Zielgruppe → generisches Produkt → keine Zielgruppe findet einen
• Vage Problemstellungen — „Produktivität ist schwer“ ist bedeutungslos. „Verbringt 4 Stunden/Woche mit X“ ist konkret.
• Scope Creep vor dem Launch — Jedes Feature, das „nützlich sein könnte“, verzögert den Launch. MVP-Disziplin gewinnt.
• Kundeninterviews überspringen — Auf Annahmen bauen = das Falsche bauen. 10–15 Interviews decken Lücken auf.
• Überspezifizieren — Keine 50-seitigen PRDs für Indie-SaaS schreiben. 1–2 Seiten reichen.
• Constraints ignorieren — Zeitplan und Budget prägen alles. Innerhalb der Constraints planen, statt sie zu ignorieren.
• Ohne Planung direkt ins Prompten — Baugeschwindigkeit multipliziert die falsche Richtung.
• Keine Datenmodell-Planung — Das Datenmodell später umzubauen ist teuer; vorab planen.
• Keine Erfolgskriterien — Ohne Ziele weiß man nicht, ob man erfolgreich war.
• Planung als Zeitverschwendung ansehen — Pre-Build zahlt sich vielfach aus.
• Sich nicht auf die Planung einlassen — Halbfertige Planung erzeugt halb-klare Prompts.
• Planung als einmalig behandeln — Pläne entwickeln sich weiter; überarbeiten, sobald man von Nutzern lernt.

Die realistische Zeitaufteilung

Pre-Build macht ~10 % der Gesamtprojektzeit aus, entscheidet aber, ob die übrigen 90 % etwas Nützliches hervorbringen.

Häufig gestellte Fragen

F1: Wie lange sollte die Planung dauern? 1–3 Stunden für die Dokumente; 10–20 Stunden inklusive Kundeninterviews. Weniger als 1 Stunde deutet darauf hin, dass wichtige Teile übersprungen wurden. Mehr als 10 Stunden allein für Dokumente deutet auf Überplanung hin — mit dem Bauen anfangen.

F2: Kann ich im Kopf planen oder muss ich es aufschreiben? Aufschreiben. Der Akt des Schreibens erzwingt Klarheit. Vage Absichten werden zu konkretem Text. Pläne, die man nicht formulieren kann, sind keine Pläne; es sind Hoffnungen.

F3: Was, wenn ich meine Nutzer noch nicht kenne? Dann ist der erste Schritt nicht das Bauen; es ist Customer Discovery. Vor jedem Design mit 10–15 potenziellen Nutzern sprechen. Bauen ohne Nutzerkenntnis führt dazu, das Falsche zu bauen.

F4: Sollte ich KI zur Planung nutzen? Ja — KI kann bei der Interviewvorbereitung helfen, Features brainstormen, PRD-Abschnitte entwerfen. Aber mit echten Kunden validieren; sich nicht auf KI verlassen, um die eigenen Nutzer zu verstehen. KI generiert plausibel klingende Planung; nur echte Kunden sagen, ob sie stimmt.

F5: Was ist mit dem Iterieren des Plans beim Lernen? Ja — Pläne entwickeln sich weiter. Der Pre-Build-Plan ist der Ausgangspunkt; überarbeiten, sobald Kundeninterviews und frühe Nutzung neue Erkenntnisse liefern. Nicht starr an V1-Plänen festhalten.

F6: Wie detailliert sollte das Datenmodell sein? Detailliert genug, um nützlich zu sein; nicht so detailliert, dass es unbrauchbar wird. Kernentitäten, Kernbeziehungen, Kern-Constraints (RLS für Nutzerdaten). 5–10 Entitäten für typisches SaaS. Nicht versuchen, jede Spalte vorab zu spezifizieren.

F7: Was, wenn die KI etwas anderes generiert als geplant? Iterieren. KI generiert basierend auf dem Prompt; den Prompt oder den generierten Code verfeinern. KI-Output als Entwurf behandeln, nicht als final. Der Plan ist die Spezifikation; KI hilft, sie auszuführen.

Fazit

• Die meisten KI-gebauten Apps, die scheitern, wurden schlecht geplant, nicht schlecht gebaut. KI hat die Bauphase komprimiert; Plandisziplin zählt mehr, nicht weniger.
• Pre-Build-Checkliste: Zielnutzer (konkret), Problemstellung (konkret), Datenmodell (Entitäten und Beziehungen), Integrationen (externe Dienste), Erfolgskriterien (quantitativ + qualitativ), MVP-Umfang (Drin-/Draußen-Listen), Constraints (Zeit/Budget/Fähigkeiten).
• Deliverables: 1-seitiges PRD, Datenmodell-Skizze, optionale Wireframes, detaillierter Prompt. Gesamtzeit: 1–3 Stunden für Dokumente; 10–20 Stunden inklusive Kundeninterviews. ~10 % der Gesamtprojektzeit.
• Kundeninterviews überspringen bedeutet, auf Annahmen zu bauen. Vor dem Bauen mit 10–15 potenziellen Nutzern sprechen.

Vor der nächsten KI-gebauten App diese Checkliste durcharbeiten. Die Investition zahlt sich in vermiedenem Neubau vielfach aus. Baugeschwindigkeit ohne Planung erzeugt schnelles Scheitern; Planung plus Baugeschwindigkeit erzeugt schnellen Erfolg. Die KI-Builder, die 2026 funktionierende Produkte ausliefern, sind diejenigen, die vor dem Prompten überlegt planen. Planung als die Zeit mit dem größten Hebel im Projekt behandeln. Dann mit Zuversicht bauen.