Production Readiness (MVP → Production)

Was macht Production Readiness (MVP → Production)?

Ziel: Dem Eigentümer mit Nachweisen sagen, ob ein Produkt bereit für echte Benutzer ist, was den Start blockiert und welches der kleinste Arbeitsumfang ist, um die Lücken zu schließen. Maßgeschneidert auf das Produkt – niemals eine generische 200-Punkte-Wunschliste.

Harte Regeln

1. Nachweis oder unbekannt. Jeder Punkt ist PASS / GAP / N/A / UNKNOWN, und PASS benötigt einen Nachweis (Dateipfad, Konfiguration, CI-Lauf, Dashboard, Dokumentenlink). Markiere PASS niemals basierend auf einer Behauptung in der README.
2. Maßgeschneidert nach Stufe. Fordere kein Multi-Region-Disaster-Recovery für eine Beta mit 50 Benutzern. Tagge jede Lücke mit der Stufe, auf der sie erforderlich ist.
3. Überprüfe Plattformregeln live. App-Store-, OAuth-, Zahlungs- und E-Mail-Sender-Regeln ändern sich jährlich. Bevor du eine Store-/Vendor-Anforderung zitierst, überprüfe die offiziellen Dokumente des Vendors (Websuche) und zitiere den Link + das Datum der Überprüfung.
4. Wiederverwenden, nicht duplizieren. Wenn pm-ai-shipping:ship-check, security-audit-static, performance-audit-static oder derive-tests verfügbar sind, führe sie für Code-Ebene-Nachweise aus und integriere die Ergebnisse. Diese Skill besitzt alles rund um den Code.
5. Klare Ausgabe. Der Eigentümer liest eine einseitige Scorecard; Details gehen in den Anhang und das Backlog.
6. Governance innerhalb des Workflows, nicht am Ende. Bevorzuge Checks, die dort laufen, wo gearbeitet wird (CI, PR-Vorlagen, Pre-Commit, In-Produkt-Schutzmaßnahmen) gegenüber Review-Meetings, die vor dem Start angehängt werden. Ein Gate, das nur am Ende läuft, wird zum Engpass.
7. Ausgeliefert ≠ übernommen. Die meisten Produkte stagnieren nach dem Start, weil sich Menschen und Prozesse nicht geändert haben, nicht weil der Code versagt hat. Readiness umfasst den Adoptionsplan (Domäne 13), nicht nur das System.

Readiness-Stufen

Stufe	Bedeutung	Typische Messlatte
T1 Öffentliche Beta	Echte Benutzer, niedrige Skalierung, etwas Ausfallzeit tolerierbar	Keine Geheimnislecks, robuste Authentifizierung, Backups wiederherstellbar, Fehler verfolgt, rechtliche Seiten, Rollback funktioniert
T2 GA	Zahlende Benutzer, SLA-Erwartungen	+ SLOs/Alarme/Bereitschaft, Last getestet, Runbooks, Support-Pfad, Integrations-Fallbacks
T3 Enterprise / reguliert	B2B-Verträge, PHI/PCI/Kinder, Audits	+ SSO/SCIM, Audit-Logs, DPAs/BAAs, Pen-Test, SOC 2 / HIPAA-Kontrollen, DR-Übungen

Workflow

Schritt 0 — Produkt profilieren (einmal fragen, Fragen bündeln)

Erfassen: Zielstufe und Startdatum; die eine Erfolgskennzahl und ihr Ziel (was macht diesen Start zu einem Erfolg, wie gemessen, bis wann); benannter Eigentümer und Genehmigungs-Stakeholder (Produkt, Entwicklung, Security, Legal/Privacy, Support, Marketing – Legal/Privacy am ersten Tag kennzeichnen, wenn personenbezogene Daten, KI-Ausgabe oder regulierte Benutzer betroffen sind); Oberflächen (Web, iOS, Android, Desktop, öffentliche API, CLI, Browser-Erweiterung, Dev-Tool/Plugin/Bibliothek, die an andere Entwickler verteilt wird); Hosting/Stack; Datentypen (PII, PHI, Zahlung, Minderjährigendaten); Benutzer (B2C/B2B), Regionen (US/EU/Sonstige); KI/LLM-Funktionen; Zahlungen; jede externe Integration (konsumierte APIs, empfangene Webhooks, Marktplätze/App-Stores, in denen veröffentlicht wird, SSO/IdPs). Scanne zuerst das Repo (Paketmanifeste, Env-Vorlagen, SDK-Imports), um die Integrationsliste vorzubefüllen, und bitte dann den Eigentümer nur um Bestätigung/Ausfüllen von Lücken.

Das Profil wählt aus, welche Module angewendet werden. Zeichne es oben im Bericht auf.

Schritt 1 — Nachweise sammeln

Repo (Code, CI-Konfiguration, IaC, Env-Vorlagen, Migrationen), Hosting-Dashboards/Connectors, falls verfügbar (Vercel, Railway, Supabase, Render usw.), Issue-Tracker, vorhandene Dokumentation. Führe verfügbare Audit-Skills aus. Notiere, was nicht überprüft werden konnte → UNKNOWN.

Schritt 2 — Kerndomänen (immer) + anwendbare Module bewerten

Bewerte jeden Punkt. Schweregrad: BLOCKER (kann auf Zielstufe nicht starten) / HOCH (innerhalb der ersten 2 Wochen beheben) / SPÄTER.

Schritt 3 — Liefern

1. Scorecard (1 Seite): Go / Go-with-Conditions / No-Go; Anzahl der Blockierer; RAG-Tabelle pro Domäne; Top-5-Risiken in einfachem Deutsch.
2. Lücken-Backlog: ein Ticket pro Lücke – Titel, warum wichtig, Akzeptanzkriterium, erforderlicher Nachweis zum Schließen, Stufe, Schweregrad, ungefähre Größe (S/M/L). Wenn Linear/Jira/GitHub Issues verbunden ist, biete an, sie als Projekt/Meilenstein zu erstellen; sonst eine Tabelle.
3. Härtungs-Kit (auf Anfrage): Erstelle ein Repo-spezifisches CI-Qualitäts-Gate, eine Agenten-Regeldatei (CLAUDE.md/.cursorrules), .env.example, Runbook-Stubs – basierend auf dem, was das Repo tatsächlich verwendet, kein Template-Dump.
4. Wiederholungsmodus: Bei späteren Läufen, vergleiche mit dem letzten Bericht und zeige nur, was sich geändert hat.

Kerndomänen (immer bewertet)

1. Secrets & Konfiguration – keine Secrets im Code oder Git-Verlauf (gitleaks/trufflehog über den gesamten Verlauf); .env ignoriert, .env.example vorhanden; Produktions-Secrets im Plattform-Secret-Store; separate Dev/Staging/Prod-Schlüssel; Rotationsplan und wer rotieren kann; Schritte bei geleakten Schlüsseln.

2. Identität & Zugriff – bewährter Auth-Provider oder gut überprüfte Bibliothek (keine selbstgebaute Kryptografie); serverseitige Autorisierung auf jeder Datenroute (prüfen auf IDOR / fehlende Tenant-Filter / permissive RLS); Sitzungs-/Token-Lebensdauer und Widerruf; Ratenbegrenzung bei Login, Registrierung, Zurücksetzen, OTP; MFA für Administratoren; Least-Privilege-Servicekonten; Administratoraktionen protokolliert.

3. Edge- & App-Sicherheit – HTTPS + HSTS; Sicherheitsheader (CSP, frame-ancestors usw.); strenge CORS; Eingabevalidierung an Grenzen; Datei-Upload-Limits/-Typ-Prüfungen; SSRF-Schutz bei URL-Fetchem; WAF/Bot-Schutz ab T2+; Abhängigkeitsscanning + Lockfiles; SAST in CI; SBOM und Lizenzprüfung bei T3.

4. Daten – automatisierte Backups und ein getestetes Wiederherstellen (die tatsächliche Wiederherstellungszeit aufzeichnen); Point-in-Time-Recovery, wo die DB es unterstützt; abwärtskompatible Migrationen (Expand → Migrieren → Kontrahieren); Staging verwendet keine rohen Produktions-PII; Aufbewahrungs- + Löschpfad (Löschung eines Benutzerkontos löscht tatsächlich in DB, Speicher, Logs, Vendoren); Verschlüsselung im Ruhezustand/in der Übertragung standardmäßig bestätigt.

5. Zuverlässigkeit – Timeouts bei jedem ausgehenden Aufruf; Wiederholungen mit Backoff + Jitter nur bei idempotenten Operationen; Idempotenzschlüssel für Zahlungen/Webhooks/Jobs; Hintergrundarbeit in einer dauerhaften Warteschlange; anmutige Verschlechterung, wenn eine Abhängigkeit ausfällt; SLOs definiert (Verfügbarkeit, Latenz) ab T2+; Kapazitäts-/Lasttest bei erwartetem Peak ×3 ab T2+.

6. Beobachtbarkeit – Fehlerverfolgung mit Release-Tagging (z. B. Sentry); strukturierte Logs mit Request-/Trace-IDs und PII-Schwärzung; Schlüsselmetriken (Rate, Fehler, Dauer) pro Endpunkt; Verfügbarkeitschecks von außen; symptom-basierte Alarme, die an einen Menschen weitergeleitet werden, der sie tatsächlich sieht; Dashboards für den Starttag.

7. CI/CD & Release – erforderliche Checks auf main (Lint, Typprüfung, Tests, Secret-Scan, Abhängigkeitsaudit); Preview-/Staging-Umgebung; Ein-Klick-Rollback einmal nachgewiesen; Feature-Flags für riskante Features; Migrationen sicher im Deployment ausgeführt; Release-Notes/Changelog; Branch-Schutz.

8. Tests – Tests auf kritischen Pfaden (Auth, Zahlungen, Daten-Schreibvorgänge, Berechtigungen) über einer Abdeckungs-%Schwelle; Integrationstests gegen eine echte DB; E2E-Smoke-Tests der wichtigsten Benutzerreisen, die nach dem Deployment ausgeführt werden; Vertragstests oder aufgezeichnete Fixtures für externe APIs.

9. Leistung & Kosten – Core Web Vitals / App-Start-Budgets; N+1- und fehlender Index-Check; Caching/CDN; Ausgabenalarme pro Vendor und harte Limits (Cloud, LLM, SMS, E-Mail); geschätzte Kosten pro aktivem Benutzer; Missbrauchsszenarien, die eine Rechnung in die Höhe treiben können (Registrierungs-Spam, LLM-Prompt-Schleifen, SMS-Pumping).

10. Betrieb & Support – Eigentümer/Bereitschaft benannt, auch wenn es nur eine Person ist; Incident-Prozess (Schweregrad, Kommunikation, Postmortem); Runbooks für die Top-5-Ausfallmodi; Status-Seite ab T2+; Support-Kanal und SLA; Admin-Tooling für häufige Support-Aufgaben (damit Korrekturen keine rohen SQL benötigen).

11. Recht & Vertrauen – AGB, Datenschutzerklärung, die den tatsächlichen Datenflüssen entspricht; Cookie-Einwilligung, wo erforderlich (EU/UK); DPAs mit Vendoren, die personenbezogene Daten verarbeiten; Subprozessor-Liste bei T3; Barrierefreiheitsziel (WCAG 2.2 AA) und ein Basis-Audit; Open-Source-Lizenz-Compliance; Marken-/Namensklärung für den Produktnamen.

12. Produkt-Readiness – Analytics zum Aktivierungstrichter (mit Einwilligung); Onboarding und leere Zustände; Transaktions-E-Mails zugestellt (siehe Web-Modul); Hilfe-Dokumente/FAQ; Preisgestellung/Abrechnung live, wenn kostenpflichtig; Feedback-Schleife; Kill-Switch für problematische Features.

13. Adoption & Betriebsmodell – Erfolgskennzahl und Pilot-Exit-Kriterien vor dem Start schriftlich festgelegt (was bewegt es von Pilot zu „Skalieren“ oder „Töten“); dokumentierter Release-Workflow mit benannten Genehmigern pro Risikostufe (niedrige Risiko-Änderungen = ein Reviewer, hohes Risiko = mehr) und einer vereinbarten Bearbeitungszeit, damit die Freigabe nicht ins Stocken gerät; Launch-Kommunikation (was ändert sich, was nicht, bekannte Limits); erste Benutzer-/Champion-Gruppe und eine Möglichkeit, von ihnen zu hören; In-Produkt-Hilfe, Vorlagen oder Beispiele, damit Benutzer im Tool lernen; Feedback-Schleife (Benutzerfeedback + Nutzungsmetriken) mit einem Review-Rhythmus (z. B. 30/60/90 Tage, dann vierteljährlich); Eigentümer für den laufenden Support, wenn die Nutzung wächst.

Bedingte Module

M1. Integrationen, die du konsumierst (ein Blatt pro Vendor) – Produktionskonto/-schlüssel (nicht Sandbox) und wer das Konto besitzt; Ratenlimits & Kontingente vs. erwarteter Peak; Preisobergrenze & Alarme; Auth-Typ und Token-Refresh; Webhook-Signaturprüfung, Replay-Schutz, idempotente Handler, Wiederholung/Backoff und Dead-Letter; API-Version fixiert + Deprecation-Watch (Changelog abonnieren); Timeout + Circuit Breaker + benutzersichtbarer Fallback; Vendor-Status-Seite abonniert; AGB erlauben deine Nutzung (Weiterverkauf, KI-Training, Scraping); Exit-Plan – du besitzt deine Daten/Prompts/Konfigurationen und kannst sie exportieren, Vertrag hat keine mehrjährige Bindung ohne Ausstiegsklauseln; Datenresidenz/DPA; OAuth-App-Verifizierungs-/Review-Anforderungen (z. B. Google sensitive/restricted scopes, Microsoft publisher verification, Slack/Zoom app review) – aktuelle Regeln live überprüfen.

M2. Öffentliche API, die du bereitstellst – OpenAPI/Spezifikation veröffentlicht; Versionierungs- und Deprecation-Richtlinie; API-Keys/OAuth mit Scopes, Rotation, Widerruf; Ratenlimits und Kontingente pro Schlüssel; Paginierung, Idempotenzschlüssel auf POST; konsistentes Fehlerformat; Sandbox-Umgebung; von dir gesendete Webhooks sind signiert, wiederholt und wiederspielbar; Entwicklerdokumentation + Changelog; Nutzungsmessung, wenn abgerechnet wird.

M3. Mobile & App-Stores – Vor dem Zitieren gegen aktuelle offizielle Dokumente prüfen:

• Apple: App Review Guidelines; Datenschutz-Nährwertkennzeichnung entspricht der tatsächlichen Erhebung; Datenschutzmanifest inkl. Third-Party-SDKs; In-App-Kontolöschung, wenn Konten erstellt werden können; „Mit Apple anmelden“-Regel bei Angebot von Drittanbieter-Logins; IAP-Regeln für digitale Güter; TestFlight-externe Tests; Export-Compliance.
• Google Play: aktuelle Ziel-API-Level-Frist; Datensicherheitsformular; Closed-Testing-Anforderung für neue persönliche Entwicklerkonten; Play App Signing und Upload-Key-Verwahrung; Web-Link zur Kontolöschung.
• Beide: Crash-Reporting; erzwungener/sanfter Update-Mechanismus für breaking API-Änderungen; Deep/Universal-Links; Push-Anmeldeinformationen im Besitz des Unternehmenskontos; Store-Listing-Assets, Altersfreigabe, Support-URL, Datenschutz-URL; Puffer für Review-Ablehnungen im Startplan (Tage einplanen, nicht Stunden).

M4. Web & E-Mail – benutzerdefinierte Domain, DNS im Besitz des Unternehmenskontos, Registrar-Sperre + automatische Verlängerung; SEO-Grundlagen (Titel, Sitemap, Robots, OG-Tags), wenn Auffindbarkeit wichtig ist; 404/500-Seiten; E-Mail-Sender-Auth SPF, DKIM, DMARC und One-Click-Unsubscribe für Massenmail (aktuelle Gmail/Yahoo-Sender-Regeln prüfen); Bounce-/Beschwerdebehandlung; separate transaktionale vs. Marketing-Streams.

M5. KI / LLM-Funktionen – Provider-Abstraktion oder Gateway mit Fallback-Modell; Timeouts und Wiederholungen bei 429/5xx; strukturierte Ausgabe durch Schema validiert (Zod/Pydantic); Evaluierungsdatensatz mit echten Fällen, die in CI vor Prompt-/Modelländerungen ausgeführt werden; Prompt-Injection-Abwehrmaßnahmen, wo das Modell unvertrauenswürdige Inhalte liest oder Tools aufrufen kann (Least-Privilege-Tools, menschliche Bestätigung für destruktive Aktionen); Kostenlimits pro Benutzer und global; PII-Handling und Datenaufbewahrungseinstellungen des Providers; Modell-Deprecation-Daten verfolgt; KI-Offenlegung gegenüber Benutzern, wo erforderlich; Marken-/Qualitätsschutzmaßnahmen für generierte Ausgaben (verbotene Begriffe, Tonprüfungen, menschliche Überprüfung nach Risiko gestaffelt); UI teilt den Benutzern die Grenzen mit („Fakten überprüfen“, Quellen für Behauptungen anzeigen); Prompt-/Modelländerungen zuerst in einer Sandbox mit historischen oder Beispieldaten getestet, dann auf einen kleinen Teil des Traffics ausgerollt, bevor sie für alle freigegeben werden; geplante (z. B. halbjährliche) Modell-/Vendor-Überprüfung.

M6. Zahlungen – gehosteter Checkout, um PCI-Scope zu minimieren; webhook-getriebener Status (niemals Client-Weiterleitung vertrauen); idempotente Erfüllung; Rückerstattungen, Streitfälle, Dunning; Steuererhebung pro Region; Test Clock/Sandbox abgedeckt; Umsatzabstimmung.

M7. Regulierte Daten – PHI → HIPAA: BAA mit jedem Vendor, der PHI berührt, Zugriffsprotokollierung, notwendiges Minimum. PCI jenseits von gehostetem Checkout → SAQ-Scope. Kinder → COPPA/Altersbeschränkung. EU/UK-Benutzer → GDPR-rechtliche Grundlage, DSAR-Prozess, Übermittlungen. Kalifornien → CCPA/CPRA. Zur rechtlichen Prüfung kennzeichnen; keine rechtlichen Schlussfolgerungen ziehen.

M8. B2B / Enterprise – Tenant-Isolation getestet (Cross-Tenant-Zugriffstest); SSO (SAML/OIDC) und SCIM bei T3; Audit-Log-Export; Rollen-/Berechtigungsmodell; Datenexport; Security Questionnaire-Paket (Architektur, Subprozessoren, Pen-Test, Richtlinien); Verfügbarkeits-SLA und Gutschriften.

M9. Marktplätze, auf denen du veröffentlichst – Chrome Web Store, Slack/Teams/Zoom-App-Verzeichnisse, Shopify, MCP/Plugin-Registries usw.: Listing-Anforderungen, Review-Zeitpläne, Berechtigungsbegründung, Datenschutzoffenlegungen – live überprüfen.

M10. Entwickler-Tools, Bibliotheken, Plugins & Open Source – Lizenz bewusst gewählt (Copyleft wie AGPL kann Unternehmensadoption blockieren; permissive Lizenzen wie MIT/Apache verbreiten sich schneller) und NOTICE/Drittanbieter-Lizenzen korrekt; SECURITY.md mit einem privaten Offenlegungskanal; semantische Versionierung, CHANGELOG und ein getesteter Upgrade-/Migrationspfad für gespeicherte Daten oder Konfigurationsformate; unterstützte Plattform-Matrix tatsächlich in CI getestet (OS × Laufzeitversionen × jeder Client/IDE, die es zu unterstützen vorgibt); Installation von einem sauberen Rechner für jeden dokumentierten Pfad verifiziert; Paketnamen auf jedem Registry reserviert (PyPI, npm, Plugin-Marktplätze); signierte Releases / Bauherkunft; Telemetrie aus oder Opt-in und dokumentiert; CONTRIBUTING, Verhaltenskodex, Issue-/PR-Vorlagen; ein Abschnitt „Was dies nicht ist“, damit Benutzer es nicht falsch verwenden.

Scorecard-Vorlage

PRODUKT: <Name>   ZIEL: T1/T2/T3   START: <Datum>   ENTSCHEIDUNG: GO | GO-WITH-CONDITIONS | NO-GO
Blockierer: N   Hoch: N   Unbekannt:

[gekürzt für Übersetzung]