Lastenheft für eine App: Vorlage auf einer Seite

Lastenheft für eine mobile App: die kurze Antwort

Ein gutes Lastenheft für eine mobile App passt auf eine Seite, wenn du deine eigene App baust. Es beantwortet zehn Fragen: für wen, welches Problem, welche Hauptfunktion, wie die App Geld verdient, was ohne Konto passiert, welche Daten erhalten bleiben müssen, auf welcher Plattform, was nicht in die erste Version kommt, woran du merkst, dass es funktioniert, und mit welchen Einschränkungen. Die Vorlage zum Kopieren findest du weiter unten. Du kannst auch die Vorlage samt Prüfraster herunterladen (.md), ohne Anmeldung.

Die 40-seitigen Vorlagen, die du online findest, sind für einen anderen Zweck geschrieben: für einen Kunden, der eine App bei einem Dienstleister bestellt und ein Vertragsdokument braucht. Du bist gleichzeitig derjenige, der entscheidet, und derjenige, der baut, oft mit Hilfe von KI. Dein Lastenheft dient zwei Dingen: Entscheidungen zu treffen, bevor du codest, und Claude, ChatGPT oder Cursor einen klaren Kontext zu geben, damit sie die richtige App bauen.

Ich veröffentliche meine eigenen iOS-Apps. Solys, ein Wecker mit Minispielen, und TradaZen, ein Trading-Simulator, sind im App Store. Nolera und Clic wurden von Apple abgelehnt und dann korrigiert. Das ist die Methode, die ich bei jeder davon anwende, und die schlage ich dir hier vor.

Warum eine Seite reicht, um deine eigene App abzustecken

Ein langes Dokument gibt dir das Gefühl, vorangekommen zu sein. In der Praxis wird es einmal geschrieben, selten wieder gelesen, und das Projekt entfernt sich schon in den ersten Wochen davon. Eine Seite dagegen liest du vor jeder Arbeitssession in zwei Minuten durch.

Die Platzbeschränkung hat noch einen nützlichen Effekt: Sie zwingt dich zu entscheiden. Wenn eine Antwort länger als zwei Sätze ist, ist die Entscheidung oft noch nicht gefallen. Das merkst du besser auf einem Blatt als drei Wochen später in deinem Code.

Und schließlich ist eine Seite die richtige Größe für die KI. Du kannst sie komplett in eine Unterhaltung einfügen oder in die Kontextdatei deines Projekts legen. Ein kurzes Dokument lässt sich leichter prüfen und verringert widersprüchliche Anweisungen. Es garantiert nicht, dass die KI sie befolgt: Prüfe ihre Vorschläge an diesem Rahmen.

Was gehört in ein Lastenheft für eine mobile App?

Beantworte jede dieser Fragen in ein oder zwei Sätzen.

1. Wer nutzt die App, und in welcher Situation? Nicht „18- bis 35-Jährige“. Lieber eine konkrete Person, zu einem konkreten Zeitpunkt ihres Tages.
2. Welches Problem löst die App, in einem Satz? Wenn du „und außerdem“ brauchst, beschreibst du zwei Apps.
3. Was ist DIE Hauptfunktion der ersten Version? Nur eine. Die anderen warten auf die Zahlen. Die Seite MVP einer iOS-App erklärt, wie du auswählst.
4. Wie verdient die App Geld? Abo, Einmalkauf oder kostenlos. Diese Antwort verändert die App ab dem ersten Bildschirm. Wenn du unsicher bist, lies Abo oder Einmalkauf für eine iOS-App.
5. Was kann man ohne Konto tun? Wenn du früh entscheidest, was ohne Registrierung zugänglich ist, musst du nicht den ganzen Einstiegsablauf neu bauen.
6. Welche Daten müssen einen Handywechsel überstehen? Diese Frage entscheidet, ob du ein Backend wie Supabase brauchst oder ob alles auf dem Gerät bleiben kann.
7. Nur iOS oder iOS und Android? Mein Rat für Einsteiger: zuerst iOS. Warum, erkläre ich in iOS- und Android-App gleichzeitig.
8. Was ist ausdrücklich NICHT Teil der ersten Version? Der nützlichste Abschnitt des Dokuments. Er beendet Diskussionen, bevor sie entstehen, mit dir selbst wie mit der KI.
9. Woran erkennst du, dass es funktioniert? Ein einziges Signal, messbar in den Wochen nach dem Release: gestartete Gratis-Testphasen, Abonnenten, wiederkehrende Nutzer.
10. Was sind deine echten Einschränkungen? Die Zeit, die du pro Woche investieren kannst, deine Hardware und dein Apple-Developer-Konto, das 99 $ pro Jahr kostet. Kein Mac? Kein Hindernis, wie ich in eine iOS-App ohne Mac veröffentlichen erkläre.

Die Lastenheft-Vorlage zum Kopieren

Kopiere diese Vorlage in eine Notiz oder in eine Textdatei im Stammverzeichnis deines Projekts und ersetze dann jede Zeile.

• Vorläufiger Name der App: …
• Für wen: eine Person, die … in dem Moment, in dem …
• Gelöstes Problem, in einem Satz: …
• Hauptfunktion der Version 1: …
• Was der Nutzer beim ersten Öffnen der App sieht: …
• Geschäftsmodell: Abo / Einmalkauf / kostenlos, und was kostenpflichtig ist: …
• Ohne Konto kann man: …
• Daten, die zwischen zwei Handys erhalten bleiben: keine / …
• Plattform: zuerst iOS (Android später, wenn die Zahlen stimmen)
• Nicht in Version 1: …, …, …
• Erfolgssignal: …
• Stack: React Native, Expo, Supabase falls Konten nötig, RevenueCat für Abos
• Einschränkungen: … Stunden pro Woche, Apple-Developer-Konto vorhanden oder nicht, Mac oder nicht
• Apps, deren Nutzererlebnis ich mag, und warum: …

Füge drei bis fünf Screenshots von Apps, die du magst hinzu, mit einem Wort dazu, was dir gefällt. Das sagt mehr als ein Styleguide, für dich wie für die KI.

Ein Lastenheft ist keine Wunschliste. Es ist eine Liste getroffener Entscheidungen.

Beispiel: die ausgefüllte Seite für eine fiktive App

Damit du den erwarteten Detailgrad siehst, hier die Vorlage ausgefüllt für eine für das Beispiel erfundene App, einen Lern-Timer.

• Für wen: ein Student, der abends allein lernt und nach zehn Minuten abschweift.
• Problem: Er schafft keine Lerneinheit, ohne zum Handy zu greifen.
• Hauptfunktion: eine getimte Lerneinheit starten und seine Serie geschaffter Tage sehen.
• Erster Bildschirm: ein einziger Button, um eine Einheit zu starten.
• Geschäftsmodell: Abo für detaillierte Statistiken, Basis-Einheit kostenlos.
• Ohne Konto: alles, außer der Sicherung zwischen zwei Handys.
• Nicht in Version 1: Gruppenmodus, Rangliste unter Freunden, Widgets, Android-Version.
• Erfolgssignal: Nutzer, die mehrere Tage hintereinander zurückkommen.

Achte darauf, was absichtlich fehlt: keine Liste mit zwanzig Bildschirmen, keine vorgegebenen Farben, keine Architektur. Diese Entscheidungen kommen beim Bauen, und die Seite hilft dir zu prüfen, dass sie der Hauptfunktion dienen.

Wie du dein Lastenheft nutzt, um die KI zu führen

Hier bringt deine Seite am meisten. Eine KI, die ohne Kontext codet, rät, und sie errät oft eine andere App als deine.

Leg die Seite in den dauerhaften Kontext des Projekts. Claude Code liest eine Datei CLAUDE.md im Stammverzeichnis, Cursor hat eigene Regeldateien. Füge dort dein Lastenheft ein, zusammen mit deinem Stack. Jede Anfrage startet dann von derselben Basis.

Zitiere den Abschnitt „Nicht in Version 1“, wenn die KI zu viel macht. Assistenten schlagen gern zusätzliche Funktionen vor: einen Dark Mode, eine Teilen-Funktion, eine Benachrichtigung. Deine Ausschlussliste liefert dir die fertige Antwort: nicht jetzt.

Verlange einen Plan, der die Seite respektiert. Schreib vor einem großen Arbeitspaket: „Hier ist mein Lastenheft, schlag einen Plan für die Hauptfunktion vor, code noch nicht.“ So merkst du sofort, ob der Plan von deinen Entscheidungen abweicht.

Lass sie die Seite prüfen, nicht nur den Code. Frag: „Welche Fragen in diesem Lastenheft sind unklar oder widersprüchlich?“ Das ist eine unterschätzte Nutzung der KI, und sie erspart dir Wochen Arbeit in die falsche Richtung.

Wenn du tiefer einsteigen willst: Die Fallstricke und Prüfungen habe ich in eine iOS-App mit KI erstellen ausführlich beschrieben.

Entscheidungen in Abnahmekriterien verwandeln

Eine Hauptfunktion braucht ein beobachtbares Ergebnis. Für den fiktiven Timer in diesem Beispiel ist „der Timer funktioniert“ zu vage. Schreib lieber: „Ich starte eine Einheit, die verbleibende Zeit wird angezeigt, ich kann sie stoppen und finde die letzte abgeschlossene Einheit wieder, nachdem ich die App erneut geöffnet habe.“ Entscheide separat, ob der Timer bei gesperrtem Bildschirm weiterlaufen soll: Diese Wahl kann die technische Arbeit verändern.

Ergänze für jede Funktion drei Zeilen: Aktion, erwartetes Ergebnis, Nachweis. Der Nachweis kann ein automatisierter Test für eine Berechnung sein oder eine Prüfung auf dem Gerät für einen Ablauf. Notiere auch, was nicht getestet wurde. Dieses kleine Raster verhindert, dass du einen fertigen Bildschirm mit einer einsatzbereiten Funktion verwechselst.

Hier ein ausgefülltes Raster für unseren fiktiven Timer. Das sind zu prüfende Kriterien, keine bereits bestandenen Tests:

Entscheidung aus dem Lastenheft	Zu testen	Erwartetes Ergebnis
Die Basis-Einheit ist ohne Konto zugänglich	App installieren und eine Einheit ohne Registrierung starten	Kein Registrierungsformular blockiert den Start
Eine abgebrochene Einheit zählt nicht für die Serie	Eine Einheit vor dem Ende stoppen, dann den Verlauf öffnen	Es wird keine abgeschlossene Einheit hinzugefügt
Der Verlauf bleibt auf dem Gerät	Eine Einheit abschließen, App schließen und wieder öffnen	Die Einheit erscheint genau einmal mit der richtigen Dauer
Der Basis-Timer funktioniert ohne Netz	Flugmodus aktivieren und eine Einheit abschließen	Timer und lokales Speichern bleiben nutzbar
Die detaillierten Statistiken sind kostenpflichtig	Statistiken ohne Abo öffnen	Das Angebot wird angezeigt; die Basis-Einheit bleibt zugänglich

Noch unklare Punkte werden zu Entscheidungen, die du treffen musst. Zum Beispiel: Was passiert, wenn der Nutzer während einer Einheit den Bildschirm sperrt oder die Uhrzeit des Handys ändert? Lass den Agenten das nicht stillschweigend entscheiden. Schreib das gewünschte Verhalten auf und füge den Fall dem Raster hinzu. Um diese Abnahme auf einer echten Installation zu organisieren, nutze den Leitfaden deine iPhone-App mit TestFlight testen.

Entscheiden, was raus muss, wenn die erste Version ausufert

Geh jede Funktion durch und stell eine Frage: „Kann der Nutzer ohne sie noch das versprochene Ergebnis erreichen?“ Bei unserem Timer kann eine Rangliste unter Freunden warten. Eine abgeschlossene Einheit wiederzufinden ist nötig, wenn du eine Serie von Tagen versprichst. Ein Abo-Bildschirm wird nur nötig, wenn du die Statistiken tatsächlich schon in dieser Version verkaufst.

Notiere die Entscheidung und ihren Grund im Logbuch der herunterladbaren Vorlage. So kannst du diese Wahl nach Tests überdenken, ohne das Warum des ursprünglichen Umfangs zu verlieren. Das Tutorial eine App mit Claude Code erstellen zeigt dann, wie du diesen Rahmen in begrenzte, überprüfbare Anfragen verwandelst.

Als Erfahrungsbericht: TradaZen hat nach der Veröffentlichung seinen Umfang geändert. Der Rahmen dient dazu, eine erste messbare Version herauszubringen und dann mit echtem Feedback über die nächste zu entscheiden.

Die Falle des Funktionskatalogs

Der natürliche Reflex ist, alles aufzulisten, was die App „können soll“: die Karte, den Chat, die Benachrichtigungen, das Empfehlungsprogramm, den Offline-Modus. Dieser Katalog ist das verlässlichste Zeichen für ein Projekt, das nie fertig wird, aus einem einfachen Grund: Jede Funktion, die vor dem Release dazukommt, verzögert den Moment, in dem echte Nutzer dir sagen, was zählt.

Eine gute erste Version macht eine Sache, und die gut. Vorsicht aber vor dem umgekehrten Extrem: Apple verlangt, dass eine App mehr ist als eine verpackte Website, gemäß Regel 4.2 der App Review Guidelines. Eine einzige Hauptfunktion, ja; eine leere Hülle, nein: Das ist der Ablehnungsgrund der Guideline 4.2.

Was nicht in ein Lastenheft für eine mobile App gehört

• Ein kompletter Styleguide. Ein paar Referenz-Screenshots reichen am Anfang.
• Ein Tagesplan. Dir fehlen noch die Informationen, um ihn einzuhalten. Ein Wochenziel reicht.
• Eine detaillierte technische Architektur. Wähl einen bewährten Stack und lass die Details beim Bauen entstehen.
• Funktionen „für später“, vermischt mit dem Rest. Die gehören alle in den Abschnitt „Nicht in Version 1“.

Wann solltest du dein Lastenheft aktualisieren?

Lies es zu Beginn jeder Arbeitswoche. Aktualisiere es nur, wenn sich eine Entscheidung aus einem echten Grund ändert: ein Test auf deinem iPhone, der zeigt, dass ein Bildschirm nicht funktioniert, Feedback eines Testers, eine unterwegs entdeckte Vorgabe von Apple. Wenn du es täglich änderst, steckt es nichts mehr ab.

Sobald die erste Version veröffentlicht ist, wird die Seite zur Grundlage der nächsten: Was nicht in Version 1 war, rückt nach, sortiert nach dem, was dir die Zahlen sagen. Den Überblick über den ganzen Weg, von der Idee bis zur Veröffentlichung, findest du auf der Seite eine iPhone-App erstellen.

Von der Seite zur veröffentlichten App

Wenn du die zehn Fragen beantwortet hast, hast du schon die Arbeit erledigt, die viele Projekte überspringen. Danach geht es darum, die Hauptfunktion zu bauen, sie auf deinem iPhone zu testen, die Abos anzubinden und die Unterlagen für Apple vorzubereiten.

Das ist der Weg des iOS Kit, in vier Schritten in deinem eigenen Tempo: Der erste dient dazu, die App zu wählen, die Geld bringen kann, ihr Publikum und ihren Preis, und dein Lastenheft ist der Ausgangspunkt dafür.

Du weißt nicht, ob deine Idee schon auf eine Seite passt? Die kostenlose Diagnose sagt dir, was dein Projekt heute blockiert und welchen Schritt du zuerst angehen solltest. Die Startseite zeigt dann, wie du aus diesem Rahmen mit Claude Code eine mobile App erstellst.

Ich verspreche dir weder Einnahmen noch eine Veröffentlichung: Apple gibt frei, und der Markt entscheidet über den Rest. Auch ohne das Kit reicht dir diese Vorlage für den Start.

Häufige Fragen

Wie schreibe ich ein Lastenheft für eine mobile App?

Halte dein Lastenheft auf einer Seite: zehn Fragen, ein oder zwei Sätze pro Antwort. Sie betreffen Zielgruppe, Problem, Hauptfunktion, Geschäftsmodell, was ohne Konto passiert, welche Daten erhalten bleiben müssen, Plattform, was nicht in die erste Version kommt, Erfolgssignal und Einschränkungen. Wenn eine Antwort länger als zwei Sätze ist, ist die Entscheidung oft noch nicht gefallen.

Mit welchem Programm schreibe ich ein App-Lastenheft?

Eine einfache Notiz oder eine Textdatei im Stammverzeichnis deines Projekts: Du kopierst die Vorlage hinein und ersetzt jede Zeile. Du kannst auch die Vorlage samt Prüfraster herunterladen (.md), ohne Anmeldung. Um eine KI zu führen, legst du es dann in die Kontextdatei deines Projekts.

Braucht eine App ein 40-seitiges Lastenheft?

Nein, wenn du deine eigene App baust: Eine Seite reicht. Die 40-seitigen Vorlagen im Netz sind für einen Kunden geschrieben, der eine App bei einem Dienstleister bestellt und ein Vertragsdokument braucht. Du entscheidest und baust selbst: Deine Seite dient dazu, Entscheidungen vor dem Coden zu treffen und der KI Kontext zu geben.

Wie gebe ich mein Lastenheft einer KI, die codet?

Leg die Seite in den dauerhaften Kontext des Projekts: Claude Code liest eine Datei CLAUDE.md im Stammverzeichnis, Cursor hat eigene Regeldateien. Zitiere den Abschnitt „Nicht in Version 1“, wenn die KI zu viel macht. Verlange vor einem großen Arbeitspaket einen Plan, der die Seite respektiert, ohne sofort zu coden.

Wie prüfe ich, ob eine Funktion dem Lastenheft entspricht?

Ergänze für jede Funktion drei Zeilen: die Aktion, das erwartete Ergebnis und den Nachweis. Der Nachweis kann ein automatisierter Test für eine Berechnung sein oder eine Prüfung auf dem Gerät für einen Ablauf. Notiere auch, was nicht getestet wurde, damit du einen fertigen Bildschirm nicht mit einer einsatzbereiten Funktion verwechselst.

Was gehört nicht in ein App-Lastenheft?

Vier Dinge solltest du vermeiden: einen kompletten Styleguide, einen Tagesplan, eine detaillierte technische Architektur und Funktionen „für später“, vermischt mit dem Rest. Ein paar Referenz-Screenshots reichen am Anfang, und für die Planung reicht ein Wochenziel. Die Funktionen für später gehören alle in den Abschnitt „Nicht in Version 1“.