app-offer

Was macht app-offer?

Führe es einmal komplett von Anfang bis Ende aus. Schreibe ein empfohlenes Angebot in eine Datei und setze die Alternativen in den Anhang.

Dateien

Datei	Wann lesen
reference/frameworks.md (F§)	Wenn ein Schritt „Lies F§n“ sagt. Enthält Frameworks mit App-Übersetzungen, Bewertungsrastern und Beispielen; F§16 listet als nicht anwendbar beurteilte Ideen; F§17 enthält die Läuferformeln.
reference/app-store-constraints.md (C§)	Vor den Schritten 7, 8 und 9 und bevor du einen Preis, eine Behauptung, einen Timer, eine Garantie oder einen Namen schreibst. Hat ein „Stand“-Datum. Überprüfe alles, was ausgeliefert wird, erneut.
reference/100m-offers-transcript.txt	Optional. Durchsuche es mit grep nach einem Detail. Der Skill muss auch ohne diese Datei funktionieren. Zitiere nie mehr als 15 aufeinanderfolgende Wörter.

Harte Regeln (jeder Schritt)

1. Nur ehrlich. Keine gefälschten Timer, Zähler oder Knappheit; keine gefälschten, KI-generierten oder nicht zugeschriebenen Bewertungen oder Testimonials, und lege jeden Anreiz dahinter offen; keine erfundenen „vorher“-Preise oder Gründe; keine versteckten Verlängerungsbedingungen; keine Funktionen, die nicht im Build sind. Verstöße führen zur Ablehnung von Apps (Apple 2.3.1, 5.6; Google Täuschendes Verhalten) und verstoßen gegen EU-/UK-/FTC-Regeln (C§7, C§8).
2. Jeder Dollarwert benötigt eine Begründung: gesparte Stunden x dem Stundenwert des Nutzers, der Preis der realen Alternative oder ein echter Einzelpreis. Keine Begründung, keine Zahl. Nicht bewertete Posten zählen in jedem Verhältnis als Null. Verwende niemals eine Zahl, um einen Test zu bestehen.
3. Der abgerechnete Betrag ist der prominenteste Preis. Entsprechungen pro Tag oder Monat sind klein und zweitrangig (C§2).
4. Markiere diese Risiken, wo immer sie auftauchen:
   • Behauptungen zu Ergebnissen + Fristen: Werbenetzwerke schränken sie ein (C§7); App Review entfernt Behauptungen, die die App nicht liefern oder belegen kann (2.3.1).
   • Gesundheits-, kognitive, Geld- oder Einkommensbehauptungen benötigen eine Begründung (C§7). Behaupte nur gemessene Fähigkeitssteigerungen innerhalb der App, nicht die Übertragung auf Arbeit, Schule oder das Gehirn.
   • Kinder oder Jugendliche: Kids Category, Parental Gate, COPPA und die staatlichen Altersgesetze, die für unter 18-jährige Nutzer in jeder Kategorie gelten (C§10).
   • Sensible Daten (Finanzen, Gesundheit, Intimes, Standort): C§16.
5. Eine Garantie muss auf jeder Plattform und für jeden Plan, neben dem sie angezeigt wird, einlösbar sein (C§5).
6. Markt > Angebot > Überzeugung. Behebe zuerst das schwächste Glied.
7. Paraphrasiere das Buch. Zitiere höchstens 15 Wörter auf einmal und selten.
8. Stelle höchstens 3 Fragen, nur wenn der Zielnutzer oder die Kernaufgabe nicht abgeleitet werden kann; eine davon kann die Gründerzahlen in Schritt 0.7 bündeln, wenn der Akquisitionskanal unbekannt ist. Markiere ansonsten Annahmen mit [A], Benchmark-Ersatzwerte aus C§14 mit [B] und fahre fort.
9. Connectors: Frage keine Analyse- oder Umsatz-Connectors ab, es sei denn, der Nutzer bestätigt, dass die Projekt- oder App-ID zu dieser App gehört. Frage ansonsten nach oder markiere mit [A].
10. Stil und Länge: klar und direkt, Tabellen für Bewertungsraster, keine Füllwörter. Haupttext ca. 3.000-4.000 Wörter plus Tabellen; Überlauf in die Anhänge.

Schritt 0: Aufnahme und Annahmen

1. Klassifiziere die Eingabe: ein Satz / Dokument / URL / bestehendes Repository. Das Arbeitsverzeichnis ist nur dann das Projekt dieser App, wenn die Eingabe sie oder ihren Code und ihre Notizen mit der Idee in Verbindung bringt. Behandle die Eingabe ansonsten als neue Idee: greife nicht im Arbeitsverzeichnis und schreibe nach ./<app-slug>-grand-slam-offer.md.
2. Bestehende App: Verankere dich in den Beweisen, bevor du etwas entwirfst.
   • Produkte und Preise: grep -rniE 'purchases_flutter|revenuecat|Purchases\.|offering|entitlement|productId|product_id|weekly|annual|lifetime|StoreKit|BillingClient' --include='*.dart' --include='*.swift' --include='*.kt' --include='*.ts' --include='*.tsx' --include='*.json' --include='*.storekit' --exclude-dir={build,Pods,.dart_tool,node_modules,.git} .
   • Paywall und Onboarding: Dateien namens *paywall* *onboard* *intro* *upgrade* *pro* *premium*, plus lokalisierte Kopien (.arb, .strings, strings.xml). Notiere die ausgelieferten Locales.
   • Analytics: track(, logEvent, Mixpanel/Amplitude/Firebase-Aufrufe; notiere, welche der Ereignisse paywall_view, trial_start, purchase, cancel und retention existieren.
   • Notizen: CLAUDE.md, README*, docs/, research/, Memory-Dateien, fastlane/metadata, CHANGELOG und Dateien, die auf *brand* *voice* *tone* *style* *listing* *aso* *keyword* *mascot* *pricing* *monetis* *paywall passen (auch Bilder).
3. Beweis-Modus. Mit WebSearch/WebFetch: Verwende etwa 12 Suchanfragen für 5-10 Wettbewerberpreise und -bewertungen, 1-3 Sterne-Bewertungsthemen für die Top 3 und einen Community-Thread; zitiere URL und Datum in Anhang B. Ohne Web: Markiere jedes Element mit [A: memory, unverified] und liste es unter „Vor der Preisgestaltung zu überprüfen“. Keine Live-Daten: Verwende benannte C§14-Zeilen als [B]-Ersatzwerte (Rückerstattungsrate = Kategorie-Rückerstattungszeile; bezahlte Zeiträume gemäß F§17.1; Traffic = Installationen x Anteil, der die Paywall erreicht). Vor dem Start: Review-Mining ist „n/a: pre-launch“; minestattdessen die Bewertungen der Wettbewerber.
4. Aktuelles Angebot in den drei Teilen des Buches: was sie bekommen, wie sie zahlen, die Bedingungen (F§1.2). Neue Idee: „Vorher“ = die Idee wie angegeben (reine Funktion, kein Angebot).
5. Bestehende App: Prüfe die aktuelle Paywall und das Onboarding auf C§2, C§7 und C§8 (Ausblenden, Offenlegungen, geschätzte Angaben, implizierte Ergebnisse, Abzeichen). Liste Verstöße in §0. Sie werden zuerst ausgeliefert, unabhängig vom Angebot.
6. Frühere Entscheidungen, die in Notizen oder Memory gefunden wurden, werden zu Einschränkungen in §0, jeweils markiert als behalten oder anfechten (mit Begründung). Überschreibe niemals stillschweigend eine; setze den Herausforderer in Anhang A.
7. Gründerzahlen (Standardwerte [A]): Umsatzziel (100.000 $/Jahr netto nach Gebühren); Akquisitionskanal (organisch); Baukapazität (allein, Teilzeit); Store-Gebühr (15 % bei Small Business Program, sonst 30 %; Google gemäß C§1); Umsatzsteueranteil am Brutto (aus Storefront-Mix, sonst 8 %); Einkommensteuersatz (30 %); Avatar-Stundenwert (lokaler Medianlohn); Paywall-Aufrufe pro Woche (gemessen, sonst 300).
8. Flags: Kinder oder jugendliche Nutzer; Gesundheits-, kognitive oder Geldbehauptungen; sensible Daten; variable Kosten pro Nutzer (Inferenz, menschliche Minuten, SMS, Drittanbieterdaten- oder API-Gebühren wie Bankaggregation, OCR oder KYC, Speicher); Mehrbenutzerprodukt (Paar, Familie, Team, Klasse: wer muss für den Wert beitreten, wer zahlt); möglicher Missbrauch gegenüber einem gefährdeten Nutzer (Zwang, Überwachung, Minderjährige).

Schreibt §0, plus die „Vorher“-Spalte, die in §11 und §12 verwendet wird.

Schritt 1: Markttest der hungernden Menge (Lies F§2)

Test	1	3	5	Beweis
Schmerz	Nette-Haben, niemand beschwert sich	Wiederkehrendes Ärgernis	Verzweifelt, teuer oder peinlich; unaufgefordert vorgebracht	1-3-Sterne-Bewertungen der Wettbewerber, Reddit, Suchbegriffe
Kaufkraft	Zahler kann nicht zahlen (Kinder, Arbeitslose)	Gemischt	Zahler hat Geld und einen Grund (Karriere, Prüfung, Gesundheit, Eltern)	Zahler vs. Nutzer, Storefront-Mix, nutzergeografischer LTV (C§14)
Leicht zu erreichen	Kein Treffpunkt, kein Keyword	Einige Kanäle	Eigener Keyword-Cluster, Communities, Ersteller; eine benutzerdefinierte Produktseite könnte nur zu ihnen sprechen	ASA-Keyword-Popularität, Subreddits, Ersteller
Wachsend	Schrumpfend oder kurz davor, vom Betriebssystem oder einer kostenlosen KI absorbiert zu werden	Stabil	Rückenwind (demografisch, Plattform, Jahreszeit, Regulierung)	Kategorientrends, „Sherlock“-Risiko

• Ordne die App Gesundheit, Wohlstand oder Beziehungen zu. Reine Unterhaltung: sage es; schmerzbasierte Preisgestaltung ist dort schwächer.
• Bewerte Kandidaten: den Markt wie angegeben (bestehende App: die Stufe, die das aktuelle Listing und die Marke bedienen) plus 2-4 Untergruppen.
• Urteil. Es beurteilt den Markt wie angegeben (bestehende App: die Stufe, die das aktuelle Listing und die Marke bedienen). Prüfe in dieser Reihenfolge:
  1. PIVOT: Kein Kandidat hat jeden Test bei 3+. Sage es deutlich; das Angebot kann es nicht beheben.
  2. GO: Der Markt wie angegeben hat jeden Test bei 3+ und insgesamt 14+. GO (normaler Markt): Er hat jeden Test bei 3+, insgesamt 12-13, und keine Untergruppe mit jedem Test bei 3+ erzielt eine höhere Punktzahl; das Angebot trägt es (F§2.7).
  3. EINENGEN: Ansonsten. Nimm die Untergruppe mit der höchsten Punktzahl, die jeden Test bei 3+ hat; gib ihre Punktzahl an, ob sie GO erreicht, die Lücke und was sie schließen würde.
• Bestehende App bei EINENGEN: Behalte die Haupt-Paywall auf der aktuellen Stufe, es sei denn, der Nutzer bittet um eine Neupositionierung. Füge die Untergruppe als Onboarding-Zielpfad, eine benutzerdefinierte Produktseite und ein eigenes Offering hinzu; bewerbe es erst, nachdem sein Inhalt ausgeliefert ist und es einen Test gewonnen hat.
• Bewerte Markt / Angebot / Überzeugung als großartig / normal / schlecht. Gib an, wo die Anstrengung zuerst hingeht.
• Nischenleiter: 4 Stufen von generisch bis hyperspezifisch, mit der Preisimplikation jeder Stufe. Erwarte ungefähr eine 2-5-fache Prämie auf der Leiter, nicht die 100-fache des Buches (F§16). Die Stufe, auf die du dich festlegst, ist der Markt wie angegeben bei GO, sonst die EINENGEN-Untergruppe (bestehende App: die obige Regel).
• Avatar: 4 konkrete Qualifikationsmerkmale, für wen es NICHT ist und wer durch das Produkt oder seine Zweckentfremdung geschädigt werden könnte (und welche Angebotselemente opt-in oder ausgeschlossen werden).
• Positionierung: „Wir helfen [Avatar], [Ergebnis] zu erreichen, indem wir [einzigartiger Mechanismus] nutzen, ohne [tiefste Angst].“
• TAM: Erreichbare Zahler x LTGP pro Zahler = Obergrenze. Neue Idee: vorläufiger LTGP = Kategoriemedian-Jahrespreis x (1 - Gebühr) x (1 - Umsatzsteueranteil) x 1,3 Zeiträume [A]; neu berechnen in Schritt 7 und §1.3 aktualisieren, wenn sich das Urteil ändert. Plane eine benachbarte Nische nur, wenn die berechnete Obergrenze, nicht ein Plateau, unter dem Ziel liegt; ein Plateau bedeutet, verbessere zuerst das Angebot.
• Festlegen. Andere Avatare werden später zu benutzerdefinierten Produktseiten oder Onboarding-Pfaden. Springe nicht zwischen Nischen, nachdem ein Test fehlgeschlagen ist.

Schreibt §1.

Schritt 2: Commodity-Check (Lies F§1.6, F§4.10, F§4.12)

• Liste mindestens 5 Substitute einschließlich der kostenlosen auf: 2-3 benannte Konkurrenz-Apps, YouTube/TikTok, ChatGPT oder eine andere kostenlose KI, die Betriebssystemfunktion, Stift und Papier / ein Buch / ein Tutor und nichts tun. Sammle Preise und Bewertungsthemen gemäß Schritt 0.3.
• Tabelle: Substitut | Geldkosten | Zeit bis zum Ergebnis | Aufwand | Traum / Wahrscheinlichkeit / Zeit / Aufwand bewertet mit 0, 0,5 oder 1 (1 = begünstigt den Käufer: großer Traum, hohe Wahrscheinlichkeit, kurze Zeit, geringer Aufwand) | Gesamt /4 | Warum jemand es wählt.
• Beantworte: (1) Wie vergleicht ein Interessent diese in der Store-Suche (Symbol, Screenshot 1, Bewertung, Preis)? (2) Wo gewinnt diese App an Zeit oder Aufwand? Schnell schlägt kostenlos. (3) Welcher eine Satz macht sie zu einer Kategorie für sich (benannte Methode + Avatar + Ergebnis + Intervall)? Wenn es erklärt werden muss, scheitert es.

Schreibt §2.

Schritt 3: Wertgleichungsprüfung (Lies F§4)

Wert = (Traumergebnis x Wahrgenommene Wahrscheinlichkeit) / (Zeitverzögerung x Aufwand und Opfer). Bewerte jeden Treiber mit 1-5; höher ist immer besser, daher werden Zeit und Aufwand danach bewertet, wie klein sie sind. Kalibriere auf den natürlichen Rhythmus der App (tägliches Spiel, wöchentliches Budget, monatlicher Bericht); F§4.11 enthält Beispiele für drei App-Typen.

Treiber	App-Maßstab	1	5
Traumergebnis	Das Ergebnis, wie es Gleichaltrige oder Partner des Nutzers bemerken würden	Eine Funktion („Pro freischalten“)	Ein spezifisches Ergebnis plus ein Intervall, in einer für die Peer-Group oder den Partner des Nutzers relevanten Szene
Wahrscheinlichkeit	Bewertung und Anzahl, gemessene Ergebnisstatistiken, persönliche Ausgangsbasis, personalisierter Plan, Demo des Ergebnisses, Fit-Signale, Risikoumkehr	Kein Nachweis	Ausgangsbasis + „Leute wie du“-Daten + Plan + Garantie
Zeitverzögerung	Zeit bis zum ersten spürbaren Gewinn; ein gemessener Gewinn vor Ablauf der Testphase oder der ersten Verlängerung; sichtbarer Fortschritt	Kein spürbarer Gewinn vor der ersten Abbuchung	Spürbarer Gewinn innerhalb der ersten Sitzung (Ziel in Sekunden); gemessener Gewinn vor Ablauf der Testphase
Aufwand & Opfer	Tippen, Tippen, Konto, Einrichtung, Berechtigungen, Minuten pro Zyklus, Willenskraft, Peinlichkeit	Konto + Einrichtung + Berechtigungsbarrieren vor dem Wert; lange Sitzungen	Nur die Schritte, die die Kernaufgabe wirklich benötigt, keine vor dem Wert; Fehler bleiben privat

• Für jeden Treiber bei 3 oder weniger liste logische Korrekturen (Änderung des Builds) und psychologische Korrekturen (Fortschrittsbalken, Planbildschirm, Countdown bis zur nächsten Freischaltung, tägliche Einrahmung, Umbenennung) auf. Versuche zuerst psychologische; sie sind billiger.
• Treibe den Nenner gegen Null: Wie würde die Version „für dich erledigt“ aussehen?
• Nenne den langfristigen Traum und die Vorteile, für die die Leute bleiben, mit Meilensteinen im Rhythmus der App (z. B. Tag 1 / 3 / 7 / 30).

Schreibt §3 (Vorher-Werte; Nachher-Werte werden in Schritt 11 hinzugefügt).

Schritt 4: Probleminventar (Lies F§7.2)

1. Gehe die Reise durch: Entdecken > Store-Seite > Installieren > Onboarding > erste Sitzung > (Mehrbenutzer: Einladung gesendet > zweiter Benutzer tritt bei) > Tag 2 > erste Woche > Plateau oder Langeweile > Abrechnung und Verlängerung > Lebensereignisse (Reise, arbeitsreiche Woche, neues Telefon, gemeinsames Gerät) > Teilen > das nächste Problem nach dem Erfolg.
2. Überprüfe in jeder Phase vier Kategorien: Es ist es nicht wert (Traum); Wird für mich nicht funktionieren / Ich werde nicht dabei bleiben (Wahrscheinlichkeit); Zu schwer / Ich werde dumm aussehen (Aufwand); Zu langsam / Keine Zeit (Zeit).
3. Schreibe jedes Hindernis in den eigenen limitierenden Glaubenswörtern des Nutzers. Durchsuche Bewertungen, Reddit, Support-E-Mails, Kündigungsgründe, Onboarding-Abbruch (vor dem Start: Bewertungen der Wettbewerber).
4. Markiere jedes mit seinem Treiber. Strebe 20+ an; 30-60 ist normal. Ordne nach Häufigkeit x Schweregrad.

Hauptteil: die Top 25 Zeilen (# | Stufe | Wörter des Nutzers | Treiber | Quelle). Der Rest geht in Anhang D.

Schreibt §4.

Schritt 5: Lösungen und Liefervehikel (Lies F§6, F§7.3-7.8)

1. Verwandle jedes Problem in „Wie [Nutzen] erreichen, auch wenn [Hindernis]“. Hauptteil zeigt die Top 10; der Rest geht in Anhang D.
2. Liste für jedes Problem Vehikel auf: mindestens 3 für jedes der Top 10 und mindestens 1 für jedes der übrigen, bevor du eines beurteilst (auseinandergehen, dann zusammenführen). Gruppiere Probleme, die sich ein Vehikel teilen. Verwende den Lieferwürfel:

Achse	Optionen
Aufmerksamkeit	1:1 (Gründer, menschlicher Coach, KI-Tutor) / Kleingruppe (Freundesduell, Familienliga, Kohorte) / 1:Viele (Funktion, Inhalt, Rangliste, Live-Event)
Aufwand	DIY-Werkzeug / DWY-geplanter Leitfaden oder KI-Coach / DFY-Automatisierung
Medium	In-App, Widget, Benachrichtigung, Uhr, Sperrbildschirm / Live Activity, E-Mail, Chat, Sprache, Live-Sitzung, druckbar
Antwortgeschwindigkeit	Sofort 24/7 (Software, KI) / Am selben Tag / Wöchentlich

3. Ziegelübung: Ändere jedes Mal ein Attribut (Oberfläche, Format, Sitzungslänge, soziale Größe, Publikum, Zahler) und notiere neue Ideen.
4. 10x / 1/10-Test: Was würdest du zum 10-fachen Preis liefern? Wie würden Nutzer noch mit 1/10 gewinnen? Behalte die beste Idee von jedem Ende.

Schreibt §5: Problem | Wie-Zeile | Vehikel (Würfelcodes).

Schritt 6: Trimmen und stapeln (Lies F§7.9-7.11)

1. Erstelle eine unbearbeitete Liste der, sagen wir, 30-70 Funktionen und Ergebnisse. Wende das externe und interne Entfernungskriterium an (F§7.9). Staple das Ergebnis: entferne alles, was nicht zu den Top 3-5 Dingen gehört, die das Kernversprechen am direktesten liefern. Keine Menülisten; nur das, was den größten Werttreiber bewegt.
2. Stapel: Liste | Enthalten (maximal 7) | Verworfen (alles andere, mit Grund). Für jeden enthaltenen Posten: maximale Dauer bis zum Ergebnis / Gewinn. Für jeden verworfenen Posten: externe Ressource, späterer Entsperrzeitpunkt oder Plug-in-Plan.
3. Der Name des Stapels: Der eine Satz, der den gestapelten Wert und die Platzierung in der Kategorie für sich beschreibt („Die [App-Name]-Methode: [Ergebnis] in [Intervall] ohne [tiefste Angst] und mit [Kernvehikel].“ Kein Erklärungsbedarf; kein Menü von Funktionen.

Schreibt §6: Trim-Protokoll, gestapelte Liste mit Gründen, Name des Stapels.

Schritt 7: Preisstrategie (Lies F§9, F§1.9, F§17)

1. Wettbewerbspreise aus Schritt 0.3 und App-Store-Daten. Niedrigster / mittlerer / höchster Preis in der Kategorie und für ähnliche Wertstapel.
2. Wertbasierte Preisspanne:
   • Berechne den Nutzen in Geld: gesparte Stunden x Stundenwert, vermiedene Kosten oder verdienter Gegenwert. Ein Betrag für 30, 90, 365 Tage.
   • Verwende die LTGP-Formel aus F§17.1: geschätzter Lifetime-Wert abzüglich Kosten. Standard-Rückerstattungs- und Abwanderungsraten aus C§14.
3. Preisanker: Nenne den höchsten Einzelpreis, den ein Kunde für die Ergebnisse zahlen würde, und dann deinen Preis. Verwende den 3x-10x-Test (F§9.5): Kann das Angebot den 3-fachen Preis noch rechtfertigen? Den 10-fachen Preis? Der Anker sollte mindestens das 3-fache des Listenpreises betragen.
4. Preispositionierung auf der Nischenleiter (von Schritt 1): Stelle sicher, dass der Preis zur Stufe passt.
5. Store-Plattform-Preisstruktur: wöchentlich / monatlich / jährlich / lebenslang. Verwende Standard-Intervalle der Plattform (C§3) und wende den Store-Gebührenabzug für die Schwellenwertberechnung an.

Empfehle eine Preisstruktur mit 3-5 Stufen (kostenlos / monatlich / jährlich / lebenslang; ggf. Team oder Familie). Schreibe für jede Stufe den abgerechneten Preis und den effektiven Monatspreis. Gib den empfohlenen Standard (automatischer Einstieg) an.

Schreibt §7: Preistabelle, Begründung, Anker, Stufen, Standard. Berechne den voraussichtlichen LTGP (neu) und das TAM (neu) für §1.3. Gib den geschätzten monatlichen und jährlichen Umsatz bei aktuellen Paywall-Volumina an.

Schritt 8: Knappheit, Dringlichkeit und Boni (Lies F§10)

1. Knappheit: Kann die App auf Plattformebene knappe Plätze durchsetzen (begrenzte Plätze, frühe Anwendervorteile, Warteliste)? Markiere [A: Plattformbeschränkung], wenn nicht. Keine gefälschten Timer.
2. Dringlichkeit: Bonuskategorie, Startpreis, zeitlich begrenzte Werbegeschenke, saisonale Boni (C§7: keine gefälschten Timer; erneute Überprüfung, ob die Plattform zulässt).
3. Boni: Liste von 3-5 digitalen Gütern mit niedrigen GK, die den Stapel ergänzen (Vorlagen, Checklisten, Kurse, Community-Zugang, frühe Feature-Freischaltungen). Weise jedem einen Wert zu (oder [B: Ersatzwert]). Bedingungen: Bonus endet bei Ablauf der Testphase oder Rückerstattung (C§5).
4. Verpackung: Füge Boni als Teil der Stufen hinzu, nicht als Pop-ups. Stelle sicher, dass sie den Wert des Kernerlebnisses verstärken und nicht ablenken.

Schreibt §8: Knappheits- und Dringlichkeitstaktiken, Bonusliste mit Werten, Verpackungshinweise.

Schritt 9: Name und Garantie (Lies F§11, F§12)

1. Name der App: 3 Optionen, die den Stapel und das einzigartige Ergebnis widerspiegeln. Keine generischen Namen. Jeder besteht den Test: Würde ein Nutzer, der ihn in der Store-Suche sieht, sofort wissen, was es tut?
2. Name des Angebots/der Stufe: „[App-Name] [Ergebnisversprechen]“ oder ähnlich. Keine „Pro“-Standardnamen, es sei denn, der Wertstapel besteht nur aus Premium-Features.
3. Garantie: Für jeden Plan und jede Plattform einlösbar (C§5). Typische Optionen: Geld-zurück-Garantie (Zeitraum zwischen 7 und 30 Tagen), bedingte Garantie („Wenn du [Ergebnis] nicht in [Tagen] siehst, erstatten wir dir den Betrag.“). Keine Garantie, die eine spätere Zahlung oder Bedingungen erfordert. Überprüfung der Einlösbarkeit auf jeder Plattform.
4. Offenlegung der Plattformbedingungen: ob die Garantie in der Storefront der Plattform definiert oder darüber hinausgeht (C§5.2).

Schreibt §9: App-Name (3 Optionen), Angebots-/Stufenname, Garantietext für jede Plattform, Offenlegung.

Schritt 10: Paywall-Platzierung und Onboarding-Fast-Win (Lies F§13, F§14)

1. Paywall-Platzierung: Für jede wichtige Nutzerreise (neu / wiederkehrend / konvertierend) die Paywall-Position. Typische Platzierung: nach dem ersten Wertnachweis (nicht vorher, wenn möglich). Ausnahmen: Spiele oder Tools, die sofortige Premium-Features erfordern.
2. Onboarding-Fast-Win: Der schnellste Weg zum ersten Ergebniswert (Schritt 3). Beschreibe den Ablauf: Schritt 1, Schritt 2, Schritt 3 (maximal 3 Bildschirme, Beginne mit Wert, nicht mit Kontoerstellung). Gib die geschätzte Zeit bis zum Gewinn in Sekunden an.
3. Auszahlung nach der Konvertierung: Was passiert unmittelbar nach dem Kauf? (Bestätigungsbildschirm, geführter erster Durchlauf, Community-Beitritt).
4. Abbrucherkennung: Signal, um eine Paywall erneut anzuzeigen (nach der Rückkehr, nach einem relevanten Ereignis).

Schreibt §10: Paywall-Platzierungsplan für jede Reise, Ablauf des Onboarding-Fast-Win, Auszahlung nach der Konvertierung, Abbrucherkennung.

Schritt 11: Vorher-/Nachher-Wertgleichung und Nachher-Rubrik (Lies F§4 erneut)

1. Aktualisiere die Rubrik aus Schritt 3 mit den Änderungen durch den gestapelten Wert (Schritt 6), die Preisstruktur (Schritt 7) und den Fast-Win (Schritt 10). Jeder Treiber erhält eine Nachher-Bewertung von 1-5.
2. Verbesserungsprotokoll: für jede Bewegung um 1+ Punkte: die spezifische Änderung (logisch oder psychologisch) und ihre Auswirkung.
3. Rubrik: Tabelle der Treiber auf Vorher/Nachher-Basis, mit Kommentaren.

Schreibt §11: Nachher-Wertgleichungsrubrik, Verbesserungsprotokoll.

Schritt 12: Testplan (Lies F§15)

1. Hypothese: „Indem wir [Änderung] durchführen, erwarten wir, dass [Metrik] um [X %] steigt, weil der [Treiber] [verbessert wurde].“
2. Metriken: Paywall-Ansichtsrate, Klickrate, Teststartrate, Konversionsrate, Abwanderung, Umsatz pro Nutzer (ARPU), Umsatz pro zahlendem Nutzer (ARPPU). Gib eine Basislinie und eine Zielverbesserung an.
3. Testdesign: A/B-Test (eine Variable nach der anderen). Dauer: 2-4 Wochen. Stichprobengröße (mindestens 100 Konversionen pro Variante für statistische Signifikanz).
4. Verkehrsquelle: Organisch / bezahlt / sozial. Wenn bezahlt, Tracking-Parameter.
5. Risikominderung: Führe einen Test an einem Tag mit geringem Traffic durch; Bereite einen Rollback-Plan vor.
6. Erfolgskriterien: Die Nachher-Rubrik zeigt eine Verbesserung von mindestens 1 Treiber um 2 Punkte oder 2 Treiber um 1 Punkt, und die Metrik verbessert sich um mindestens 20 % (oder statistisch signifikant, je nachdem, was größer ist).

Schreibt §12: Testhypothese, Metriken, Design, Dauer, Stichprobengröße, Erfolgskriterien. Platziere den Test im Kontext des aktuellen Paywall- und Akquisitions-Setups.

Schritt 13: Schiffsplan (Lies F§15.4)

1. Priorität: Liste der Änderungen in der Reihenfolge der Auswirkung / des Aufwands. Beginne mit dem billigsten psychologischen Fix, dann logische Änderungen, dann Paywall-Platzierung, dann neue Funktionen.
2. Abhängigkeiten: Was muss zuerst codiert werden? (Neue Stufen, Boni, Garantieneinrichtung).
3. Schätzung des Entwicklungsaufwands: Tage/Wochen für jede Phase. Markiere [A], wenn Aufwand unbekannt.
4. Meilensteine: V1 (sicherer Wert/Sicherheitskorrekturen) → V2 (Paywall-Optimierung) → V3 (neue Funktionen).
5. Launch-Kommunikation: Was wird im Store-Listing aktualisiert, Was wird sozialen Kanälen mitgeteilt, Was wird bestehenden Nutzern per E-Mail mitgeteilt (sofern zutreffend).

Schreibt §13: priorisierte Aufgabenliste, Abhängigkeiten, Meilensteine, Launch-Kommunikation.

Anhänge

Anhang A: Abgelehnte Alternativen – 10-20+ abgelehnte Ideen mit Begründungen (knapp: gegen die harten Regeln; zu teuer; zu komplex; nicht für den Avatar).

Anhang B: Wettbewerbsrecherche – 5-10 Wettbewerber mit Preisen und Bewertungen; 1-3 Sterne-Themen für die Top 3; Community-Thread (URL und Datum).

Anhang C: Gründernummern – Berechnungstabelle; Raten- und Gebührenquellen; Annahmen für Schwellenwerte (z. B. Rückerstattungsrate, Abwanderungsrate).

Anhang D: Vollständiges Probleminventar und Lösungskatalog – Alle 30-60 Einträge aus Schritt 4, mit allen Vehikelcodes aus Schritt 5.

Anhang E: Analyse der Plattformkonformität – Liste der Risiko-Flags aus Schritt 0, Punkt 8; besteht die Garantie auf jeder Plattform?; Liste der noch zu validierenden Punkte.

Anhang F: Sprachliche und kulturelle Anpassung (optional) – Wenn die App auf mehrsprachige Märkte abzielt: Notiere, wie die Wertgleichung, die Nischenpositionierung und die Garantieformulierung in jeder Sprache optimiert werden können. Gib Beispiele für Ton und Register an.

Ausgabe

Schreibe offer/grand-slam-offer.md (oder ./<app-slug>-grand-slam-offer.md für eine neue Idee, die nicht im aktuellen Projektverzeichnis lebt). Das Dokument enthält:

• Kopfzeile: App-Name, aktuelles Datum, Status (neu/bestehend).
• Alle schriftlichen Abschnitte: §0 bis §13, alle Anhänge A-F (sofern zutreffend).
• Tabellen für Rubriken, Preise und Tests. Listen für Probleme, Lösungen und Boni.
• Zusammenfassung der wichtigsten Empfehlungen am Anfang.

Beispiel (gekürzt)

# Grand Slam Offer: HabitHero

Datum: 2024-03-15
Status: Neue App-Idee

## Zusammenfassung

**Positionierung:** Wir helfen vielbeschäftigten Berufstätigen, eine nachhaltige Morgenroutine aufzubauen, indem wir KI-gesteuerte Gewohnheitsverkettung nutzen, ohne sich überfordert zu fühlen.
**Preis:** 9,99 $/Monat (Standard), 79,99 $/Jahr (effektiv 6,67 $/Monat).
**Garantie:** 30 Tage Geld-zurück, wenn du deine Routine nicht an 21 von 30 Tagen abgeschlossen hast.

## Schritt 1: Markttest
...