Production App

Was macht Production App?

Die Idee

Jedes große Unternehmen konvergiert zur gleichen Form: ein Edge davor, ein bereitstellbares Frontend, ein separates Backend hinter einem Gateway, Worker, die aus einer Queue ziehen, ein relationales System of Record, ein Cache, ein Event- oder Job-Backbone, Objektspeicher und Observability um alles herum. Shopify, Notion, Figma, Instacart und Airbnb unterscheiden sich in Sprachen und Anbietern, nicht in der Form.

Die Form ändert sich nicht zwischen einem Wochenend-MVP und einem Unternehmen mit einem Plattform-Team. Nur der Anbieter hinter jeder Box ändert sich. Daher baut dieses Skill die vollständige Form am ersten Tag mit günstigen Managed-Providern auf, erzwingt eine kurze Liste von Portabilitätsregeln und behält ein Playbook pro Schicht für den Austausch des Anbieters, wenn ein messbarer Auslöser eintritt. Auf diese Weise ist der Wechsel von Vercel und Supabase zu Kubernetes und RDS eine Reihe von Konfigurationsänderungen und Datenkopien, niemals eine Neuschreibung.

Wie man dieses Skill verwendet

1. Lies die Projektbeschreibung. Stelle die Aufnahmefragen unten nur für das, was sie auslässt.
2. Wähle einen Anbieter pro Schicht mit references/providers-and-tiers.md. Beginne mit Stufe 1, es sei denn, eine Auswahlregel besagt etwas anderes.
3. Schreibe docs/PLAN.md aus der Vorlage unten, inklusive des Diagramms aus references/architecture.md, und zeige es vor dem Gerüstbau.
4. Gerüstbau und Entwicklung in der unten angegebenen Reihenfolge.
5. Vor dem Start führe references/launch-checklist.md aus und melde nur Fehler mit Korrekturen.
6. Wenn später ein Auslöser eintritt, öffne references/migrations.md und verschiebe nur diese eine Schicht. Verschiebe niemals zwei Schichten in derselben Woche.

Für eine bestehende App: Prüfe zuerst. Ordne das Repository auf die Form ab, liste die Lücken geordnet nach Risiko (Datenleck, Ausfall, Missbrauch, Lock-in, Kosten) und stoppe. Änderungen kommen erst, nachdem der Eigentümer aus der Liste ausgewählt hat.

Aufnahme

Frage nur das, was die Beschreibung unbeantwortet lässt, in einer Nachricht.

1. Wer sind die Benutzer und was ist der Mandant: die Einheit, die Daten besitzt (ein Unternehmen, ein Gebäude, ein Händler, eine einzelne Person)?
2. Was ist schwer: Feeds, Nachrichten, Uploads, Video, Events, Suche? Ungefähre Zeilen oder Dateien pro Tag und Wachstum.
3. Web, iOS, Android oder eine Mischung? Was wird zuerst ausgeliefert?
4. Echtzeitanforderungen: Chat, Live-Präsenz, kollaboratives Bearbeiten oder reicht Polling?
5. Geld: Abonnements, einmalige Zahlungen, Marktplatzauszahlungen, keines?
6. Irgendetwas reguliertes oder sensibles: gespeicherte Zahlungen, Gesundheit, Minderjährige, Standort, Regierungs- oder Unternehmenskäufer, die nach SOC 2 fragen werden?
7. Zielgruppe Geografie: ein Land oder global?
8. Einschränkungen: vorhandene Cloud-Guthaben, ein bestehender Anbieter, eine erforderliche Sprache.

Die Antworten treiben die Auswahlregeln in references/providers-and-tiers.md.

Die Form

Jede Schicht hat eine Rolle, eine Referenz zu einem großen Unternehmen und die eine Regel, die sie portabel hält. Anbieter pro Stufe befinden sich in references/providers-and-tiers.md.

1. Edge: DNS, TLS, CDN, DDoS, WAF, Ratenbegrenzung, Bot-Filterung, vor jedem Host. Große Unternehmen: Cloudflare, Akamai, Fastly, CloudFront mit AWS WAF. Regel: Du besitzt die DNS-Zone; jeder Anbieter sitzt hinter einem CNAME, sodass ein Wechsel des Anbieters eine DNS-Änderung ist.
2. Frontend: eine separate bereitstellbare Einheit, statisch oder serverseitig gerendert, die keine Geschäftslogik und keinen Datenbankzugriff enthält. Große Unternehmen: eine React- oder Next.js-App, die in einen Container gebaut und über das CDN ausgeliefert wird. Regel: Das Frontend baut als Standard-Node-Container oder statisches Bundle und kommuniziert nur mit der öffentlichen API.
3. Gateway: ein Load Balancer oder API-Gateway, das TLS vom Edge terminiert, nach Pfad routet und grobe Grenzen durchsetzt. Große Unternehmen: ALB, Envoy, NGINX Ingress, Kong. Regel: Die API hängt niemals von Gateway-Funktionen ab, die sie nicht in ihrer eigenen Middleware reproduzieren kann.
4. Backend: ein Monolith-Dienst hinter dem Gateway, der nur bei Teamkollisionen in Dienste aufgeteilt wird. Große Unternehmen: Rails bei Shopify und GitHub, Django bei Instagram, Node bei Notion, gRPC intern, GraphQL oder REST extern. Regel: Ein Docker-Container mit einem Health-Endpunkt, Konfiguration aus Umgebungsvariablen, keinem Vendor-SDK in der Geschäftslogik.
5. Worker und Queue: separate langlebige Prozesse, die Jobs konsumieren; eine Workflow-Engine, wenn Jobs mehrere Schritte oder menschliche Wartezeiten haben. Große Unternehmen: Sidekiq- und Kafka-Konsumenten bei Shopify, Temporal bei Netflix und Duolingo, Kafka bei Notion. Regel: Jobs sind idempotent, tragen IDs keine Blobs, und die Queue ist ein Standard-Redis- oder Kafka-Protokoll.
6. Relationale Datenbank: eine Postgres- (oder MySQL-) Primärinstanz als System of Record, Replicas für Lesezugriffe, Sharding nur, wenn die Grenzen einer einzelnen Maschine überschritten werden. Große Unternehmen: RDS Postgres mit PgBouncer bei Notion und Figma, 100+ MySQL-Shards bei Shopify. Regel: Nur Postgres-Wire-Protokoll, SQL-Migrationen im Repository, Rollen und RLS in SQL, nichts, das nur mit der API eines Anbieters funktioniert.
7. Cache: Redis oder Memcached für heiße Lesezugriffe, Ratenbegrenzungszähler, Sperren, Sitzungen. Regel: Standard-Redis-Protokoll, Schlüssel mandantenbezogen und versioniert, die App muss mit leerem Cache laufen.
8. Objektspeicher: S3 oder ein S3-kompatibler Bucket für jede Datei; niemals die Datenbank. Regel: Nur die S3-API, Schlüssel mit Mandanten-Präfix, ausgeliefert über signierte URLs oder das CDN.
9. Identität: ein Identitätsanbieter, der JWTs ausgibt, eine users-Tabelle, die der App gehört. Große Unternehmen: Eigenentwicklung plus Okta oder Auth0 für Enterprise SSO. Regel: Die API verifiziert Token selbst über JWKS und besitzt die Benutzertabelle, sodass der Aussteller wechseln kann.
10. Ereignisse und Analysen: Produktanalysen und später ein Data Warehouse, das durch Change Data Capture gespeist wird. Große Unternehmen: Kafka in Snowflake oder BigQuery. Regel: Das Warehouse liest aus der Datenbank, niemals Doppelschreibvorgänge aus der App.
11. Observability: strukturierte Logs, Fehler, Metriken, Traces, Uptime, Alarme, die an ein Runbook gebunden sind. Große Unternehmen: Datadog, Grafana, Honeycomb, Sentry, OpenTelemetry. Regel: Die App sendet OpenTelemetry und JSON-Logs, sodass das Backend eine Exporter-Einstellung ist.
12. Delivery: CI bei jedem Push, Infrastruktur als Code, Canary- oder Blue-Green-Deployments, Feature-Flags, schnelles Rollback. Große Unternehmen: Terraform, Buildkite oder GitHub Actions, ArgoCD oder Spinnaker, LaunchDarkly. Regel: Alles, was in einem Dashboard angeklickt wird, wird am selben Tag in infra/ niedergeschrieben, und Terraform ab Stufe 2.

Portabilitätsregeln

Diese machen die spätere Migration kostengünstig. Sie kosten fast nichts in der MVP-Größe und sind der Unterschied zwischen einer Wochenendmigration und einer vierteljährlichen Neuschreibung.

1. Frontend und Backend sind separate Repositories und separate bereitstellbare Einheiten ab dem ersten Commit. Sie kommunizieren über eine versionierte HTTP-API mit gemeinsamen Schemas.
2. Das Backend und der Worker sind Docker-Images, die überall dort laufen, wo ein Container läuft. Keine serverlosen Funktionen für die API: Vercel-Funktionen, Lambda-Handler und Edge-Funktionen sind das eine, was später nicht ohne Neuschreibung in einen Container gehoben werden kann.
3. Kommuniziere mit der Infrastruktur nur über Standards: Postgres-Wire-Protokoll, Redis-Protokoll, die S3-API, SMTP oder eine HTTP-E-Mail-API hinter einem Interface, JWKS für Token, OpenTelemetry für Telemetrie. Die eigene Client-Bibliothek eines Anbieters ist nur in einem dünnen Adapter-Modul erlaubt, das ausgetauscht werden kann.
4. Keine Anbieterfunktion in der Geschäftslogik: keine PostgREST-Aufrufe, kein Supabase- oder Firebase-Client im Backend, keine Vercel-spezifischen Caching-APIs, kein Workers KV. Das Frontend darf nur das Auth-SDK des Anbieters für die Anmeldung verwenden.
5. Die App besitzt ihr Schema: SQL-Migrationen im Repository, angewendet durch ein Migrationstool, niemals über ein Dashboard. Rollen, RLS und Funktionen sind SQL-Dateien, die das Repository auf jeder Postgres-Instanz wiedergeben kann.
6. Die App besitzt ihre Benutzer: eine users-Tabelle, die beim ersten Login vom Identitätsanbieter gespiegelt wird, wobei die Anbieter-IDs als Spalte gespeichert werden. Berechtigungsdaten leben in den Tabellen der App.
7. Konfiguration sind Umgebungsvariablen, die beim Start validiert werden. Geheimnisse leben im Secret Store der Plattform, erreichen die App aber als Umgebungsvariablen, sodass der Store gewechselt werden kann.
8. Du besitzt die DNS-Zone (Cloudflare). Jeder Anbieter ist ein CNAME-Ziel. Nichts ist auf die Nameserver eines Anbieters gerichtet.
9. Objektspeicher-Schlüssel und Bucket-Layout sind auf R2 und S3 gleich; der Code verwendet das S3-SDK mit einer Endpunkt-Einstellung.
10. Jede Schicht hat ein dokumentiertes Export-Verfahren: pg_dump und logische Replikation für die Datenbank, rclone für Objekte, ein Redis-Dump wird nie benötigt, weil der Cache wegwerfbar ist und die Queue sich leert.
11. Health-Endpunkte, Graceful Shutdown bei SIGTERM und horizontale Zustandslosigkeit existieren von Tag eins an, weil jede Plattform von Railway bis Kubernetes darauf angewiesen ist.
12. Telemetrie und Logs sind von Tag eins an OpenTelemetry und JSON; Vendor-Agenten werden nicht im Code installiert.

Stufen

Drei Stufen pro Schicht. Auslöser sind messbar; die vollständige Tabelle mit Anbietern, Kosten und Auswahlregeln befindet sich in references/providers-and-tiers.md.

• Stufe 1, MVP: Managed-Provider, die in Minuten eingerichtet sind und insgesamt unter etwa 150 € pro Monat kosten. Frontend auf Vercel, Backend-Container auf Railway, Postgres auf Supabase, Redis auf Railway, Objekte auf R2, Edge auf Cloudflare, Sentry und Better Stack. Bis es zahlende Kunden gibt, die nach Uptime fragen, oder die unten genannten Zahlen erreicht werden.
• Stufe 2, Wachstum: die gleiche Form in einem eigenen Cloud-Konto, wo es wichtig ist: Postgres auf RDS oder Aurora Multi AZ mit PgBouncer oder RDS Proxy, Container auf ECS Fargate oder einem kleinen EKS, ElastiCache, S3 oder R2, Terraform für alles, ein Read Replica, Temporal für Workflows. Auslöser: ein zahlender Kunde fragt nach einer SLA oder SOC 2, oder dauerhaft 5.000 monatlich aktive Benutzer mit Datenbank-CPU über 60 %, oder die PaaS-Rechnung übersteigt 500 € pro Monat, oder ein zweiter Ingenieur kommt hinzu.
• Stufe 3, Skalierung: das, was Shopify und Notion betreiben. Kubernetes mit Autoscaling, shardierte oder partitionierte Primärinstanz, Kafka als Event-Backbone, Data Warehouse via CDC, Multi-Region-Lesevorgänge, Datadog oder Grafana, ein Plattform-Team. Auslöser: dauerhaft 1.000 Anfragen pro Sekunde, eine einzelne Primärinstanz nahe 1 TB oder schreibbegrenzt nach Replicas und Caching, eine Multi-Region-Anforderung oder ein Betriebsteam existiert, um es zu betreiben.

Der Wechsel der Stufen erfolgt pro Schicht, nicht auf einmal. Die Datenbank wird in der Regel zuerst verschoben, dann das Backend, dann zuletzt das Frontend, weil das Frontend am günstigsten dort zu belassen ist, wo es ist.

Build-Reihenfolge

1. Schema, Migrationen, Rollen, RLS (references/database.md, references/security.md).
2. Identitätsüberprüfung und Mandantenkontext-Middleware.
3. Kern-API-Routen mit Validierung und Idempotenz bei Schreibvorgängen.
4. Ratenbegrenzungs- und Caching-Middleware (references/rate-limiting.md, references/caching.md).
5. Worker und Queues; alles Langsame oder Externe verlässt den Anfragepfad (references/jobs-and-queues.md).
6. Frontend gegen die API.
7. Mobile gegen die gleiche API.
8. Logs, Metriken, Traces, Health Checks, Alarme (references/observability-and-reliability.md).
9. Start-Gate, Lasttest bei dreifacher erwarteter Spitze, ein Wiederherstellungstest (references/launch-checklist.md).

PLAN.md-Vorlage

# <Projekt> Plan
## Produkt in drei Sätzen
## Benutzer, Mandant, Rollen
## Anbieter pro Schicht         (Stufe pro Schicht, warum, der Auslöser, der sie verschiebt, aus providers-and-tiers.md)
## Datenmodell                 (Tabellen, tenant_id markiert, Indizes, partitionierte Tabellen)
## API-Oberfläche              (Routen nach Ressource, Auth-Level, Ratenbegrenzungsstufe)
## Hintergrundjobs            (Queue, Auslöser, Idempotenz-Schlüssel, Wiederholungsrichtlinie)
## Drittanbieter              (Dienst, Zweck, Geheimnisname, Grenze, Fehlermodus)
## Caching-Plan                (Was, Schlüssel, TTL, welche Schreibvorgänge es ungültig machen)
## Bedrohungsmodell            (Top 5 Missbrauchsfälle und die Kontrolle für jeden)
## Skalierungsannahmen         (Benutzer, Zeilen, Anfragen pro Minute beim Start und bei 10x)
## Kosten beim Start           (pro Anbieter, pro Monat)
## Exit-Plan pro Anbieter     (das migrations.md-Playbook, das zutrifft, in einer Zeile pro Stück)
## Diagramm

Nicht verhandelbare Regeln

1. Jede mandantenbesessene Tabelle hat tenant_id; RLS aktiviert und erzwungen; die API setzt den Mandanten pro Transaktion aus verifizierter Mitgliedschaft, niemals aus Anforderungseingaben.
2. Clients greifen niemals auf die Datenbank zu oder halten privilegierte Schlüssel. Alles geht durch die API.
3. Jede Eingabe wird an der Grenze validiert, unbekannte Schlüssel werden abgelehnt; jede Abfrage ist parametrisiert.
4. Die API und Worker verbinden sich über einen Pooler mit kleinen Pools; Anweisungs-Timeouts werden pro Rolle gesetzt.
5. Ratenbegrenzungen am Edge und in der API, pro Benutzer, Mandant und IP geschlüsselt. Cache-Schlüssel sind mandantenbezogen und versioniert.
6. Geheimnisse im Platform Store, ein Satz pro Umgebung, niemals in Git oder einem Mobile-Bundle. Produktion und Staging sind separate Projekte und Konten.
7. PITR ist aktiviert und eine Wiederherstellung einmal getestet.
8. Webhook-Signaturen verifiziert, Replay-geschützt, idempotent, in unter zwei Sekunden beantwortet.
9. Timeouts bei jedem ausgehenden Aufruf; Wiederholungen mit Jitter nur bei idempotenter Arbeit; fehlgeschlagene Jobs für einen Menschen sichtbar.
10. Request-ID und Mandanten-ID in jeder Logzeile; Alarme bei Fehlerrate, p95-Latenz, 5xx-Anzahl, Queue-Alter, fehlgeschlagenen Jobs, Datenbankverbindungen.

Mobil

1. Bestehende React Native- oder Expo-App: bleibt.
2. Neue App, nur iOS oder iOS zuerst: nativ mit Swift und SwiftUI. Große Unternehmen sind 2026 zu nativ zurückgekehrt (Shopify zurück zu Swift und Kotlin, Notion zu SwiftUI), weil Codierungsagenten die Kosten der zweiten Codebasis beseitigt haben; das Gleiche gilt für ein kleines Team. Kotlin nur, wenn Android tatsächlich gebaut wird.
3. Neue App, die iOS und Android am selben Tag mit ein oder zwei Personen ausliefern muss: Expo.
4. In jedem Fall kommuniziert die App nur mit der API, bewahrt Token in sicherem Speicher auf und liefert nichts Geheimes im Bundle aus.

Referenzdateien

• references/providers-and-tiers.md: die Tabelle pro Schicht (Best Practices großer Unternehmen, Stufe-1-, 2- und 3-Anbieter, Auslöser, Kosten) und die Auswahlregeln, die eine Projektbeschreibung in Entscheidungen umwandeln.
• references/migrations.md: das Schritt-für-Schritt-Playbook zum Verschieben jeder Schicht auf eine höhere Stufe.
• references/architecture.md: das Diagramm mit Stufenbezeichnungen, den drei Anforderungspfaden, Repository-Strukturen, Umgebungen, Edge- und Plattformkonfiguration.
• references/security.md: Mandantenfähigkeit und RLS, Identität, Geheimnisse, Header, Eingabe, Uploads, Webhooks, Verschlüsselung, Löschung und Export, Mobil, Audit-Log, Vorfälle.
• references/rate-limiting.md: vier Schichten mit Zahlen und der Middleware.
• references/caching.md: jede Cache-Schicht, Schlüsselschema, TTLs, Ungültigmachung, Stampede-Schutz.
• references/database.md: Schema-Regeln, Rollen, Pooling, M

…

[gekürzt für Übersetzung]