From 83d4e93f384429644a29dbc99c94d9e75803ab62 Mon Sep 17 00:00:00 2001 From: chahinebrini Date: Mon, 11 May 2026 16:00:30 +0200 Subject: [PATCH] =?UTF-8?q?docs(pricing):=20mail=3Dsafety-feature=20for=20?= =?UTF-8?q?this=20audience,=20target-group=20device/mailbox=20reality,=20f?= =?UTF-8?q?ounding-members=20(first=20100=20=E2=86=92=20Pro)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 4.7 (1M context) --- ops/strategy/pricing-tiers.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/ops/strategy/pricing-tiers.md b/ops/strategy/pricing-tiers.md index 614c8c5..e4d71dd 100644 --- a/ops/strategy/pricing-tiers.md +++ b/ops/strategy/pricing-tiers.md @@ -41,6 +41,10 @@ **Strategische Wette (User, „kenne die Zielgruppe sehr gut"):** *Voller* Schutz = **Legend-only** ist Absicht. Die Wette: ein Mensch in Recovery wandert nach ein paar Monaten **von selbst** zu Legend (mindestens als Probe), weil die Sucht gegen Lücken arbeitet — irgendwann will er *alles* dicht (Multi-Device, volle Blocklist, Echtzeit-Mail). Bedingungen, damit diese Wette aufgeht: (1) das **Front-Door-Erlebnis** darf den User nicht in Woche 1 verlieren (Relapse auf einer offensichtlichen Seite / Deinstall / 1-Stern) — die kuratierte Kernliste ist genau die *Infrastruktur* dafür, nicht ein Widerspruch zur „Legend = voll"-Strategie: sie kauft die Zeit, bis die Wette greift. (2) Die App muss **transparent** sein, dass Legend = voller Schutz ist (z.B. „Grundschutz aktiv — voller Schutz vor allen bekannten Glücksspiel-Seiten: Pro/Legend") — der User muss die Treppe *sehen*, um in sie hineinwachsen zu können; „versteckt" wäre die Strategie nur ggü. dem *Markt*, nicht ggü. dem einzelnen Nutzer. Restrisiko bleibt der Front-Door-Drop (Strategist §7.1) — vom User bewusst akzeptiert. +**Founding Members (User, 2026-05-11):** Die **ersten 100 User bekommen automatisch Pro** — als „Founding Members". Launch-Taktik: Early-Adopter belohnen, den Community-Nukleus seeden, Word-of-Mouth + Feedback. Passt zur Community-Conversion-Philosophie (die ersten 100 sind die wachsende Community, die spätere User sehen). Offene Details: (a) Dauer — *lifetime* Pro (Standard für „founding member") oder N Monate? Annahme: lifetime. (b) Badge — „Founding Member"-Abzeichen in Profil/Community (Status/Anerkennung)? Annahme: ja. (c) Founding Member will später Legend → zahlt vollen Legend-Preis (sein Pro ist Geschenk, kein Rabatt-Anker); kündigt er ein bezahltes Legend → fällt zurück auf Founding-Pro, nicht auf Free. Impl (Phase 2, rebreak-backend): Signup-Counter / `foundingMember`-Flag auf dem Profil, für die ersten 100 automatisch gesetzt + `plan='pro'` (exempt von normaler free→pro-Logik und von Downgrade-Reconciliation); Badge im Frontend. + +**Zielgruppen-Realität (korrigiert Strategist-Annahmen §7.2):** Der Mail-Newsletter-Schutz ist für diese Zielgruppe ein **Sicherheits-Feature, kein Komfort** — eine einzige Casino-Mail kann realen Schaden verursachen (der Strategist's „die meisten kriegen wenige Casino-Mails" / „Daemon = Garnitur #3" gilt nicht für jemanden in Recovery). Außerdem: Zocker/Süchtige haben typischerweise **mehr als ein Gerät** und **mehr als 3 Mailboxen** (in DE besonders — viele E-Mail-Adressen, Wegwerf-Accounts, neue Accounts während aktiver Sucht). → Die Free/Pro-Limits (1 Gerät, 1 bzw. 3 Mailboxen) liegen *absichtlich unter* dem, was ein ernsthafter Betroffener braucht — das ist der Funnel zu Legend (∞ Mailboxen + Echtzeit-IMAP-Daemon + Multi-Device-DNS). Implikation für Phase 2: das Daemon-Gating ist kein „nice to have", und `mo` muss einplanen, dass ein Legend-User *viele* gleichzeitige IDLE-Sessions hat (Skalierung des `imap-idle`-Daemons). + **Offene Implementierungs-Punkte (→ Phase 2, eigener Workstream):** 1. **Kuratierte Free-Kernliste** — Subset der HaGeZi-Liste nach Popularität/Traffic-Rang filtern (~1–2k), ~monatlich nachziehen. Neue `getPlanLimits`-Achse `globalBlocklist: 'curated' | 'full'` (oder Boolean + zweites Listenfile). → rebreak-backend. 2. **IMAP-IDLE-Daemon-Gating auf Legend** — Daemon (`backend/imap-idle/`) hält nur für Legend-`MailConnection`s eine IDLE-Session; free=4h-fixed-Cron, pro=Intervall-Wahl (1/4/8h), legend=Live. → rebreak-backend + mo.