Von Vibe Code zu Enterprise-Software: Die Production-Readiness-Checkliste

Dein KI-gestützter Prototyp funktioniert. Nutzer registrieren sich, erste Umsätze tröpfeln herein, und ein ernsthafter Enterprise-Kunde hat gerade nach einem Security-Fragebogen und einem Referenzarchitektur-Diagramm gefragt. Das ist der Moment, den jeder Gründer, der mit Cursor, Claude oder Copilot baut, irgendwann erreicht. Und es ist der Moment, in dem eine demo-taugliche Codebasis zu etwas werden muss, das ein Enterprise-Einkaufsteam tatsächlich abnimmt.

Dieser Übergang hat einen Namen. Er heißt Production Readiness, und er ist die Lücke zwischen "es läuft" und "es läuft zuverlässig, beobachtbar und prüfbar unter feindlichen Bedingungen". Die Production-Readiness-Checkliste unten ist die, die wir bei Wolf-Tech in jedem Vibe-Code-Rescue-Projekt durchgehen, das wir übernehmen. Sie ist bewusst meinungsstark, geschrieben für Symfony/PHP- und Next.js/TypeScript-Stacks, und sie existiert, weil KI-generierter Code immer wieder dieselben Lücken an denselben Stellen hinterlässt.

Dreißig Punkte, gruppiert in sechs Bereiche. Du wirst am ersten Tag nicht jeden bestehen. Das Ziel ist zu wissen, wo du stehst, gnadenlos zu priorisieren und Lücken in der Reihenfolge zu schließen, die für deine konkreten Kunden am wichtigsten ist.

Sicherheit und Secrets: die nicht verhandelbaren Punkte

Enterprise-Kunden beginnen ihre Bewertung hier. Wer diesen Abschnitt nicht besteht, beendet Beschaffungsgespräche, bevor sie begonnen haben.

1. Alle Secrets leben außerhalb des Repositories. Umgebungsvariablen, geladen aus einem Secret Manager (AWS Secrets Manager, HashiCorp Vault, Doppler). Kein committetes .env, keine hartcodierten API-Keys, keine Fallback-Defaults im Quellcode. Lass git log -p -S "sk_" oder trufflehog über deine Historie laufen und rotiere alles, was dabei auftaucht.

2. Authentifizierung nutzt eine geprüfte Bibliothek. Symfony Security Bundle, NextAuth oder einen Identity Provider wie Auth0 oder Clerk. Niemals selbst gebaute Session-Logik. KI neigt dazu, Authentifizierung neu zu erfinden, und sie tut das meist schlecht.

3. Passwortspeicherung nutzt Argon2id oder bcrypt mit Kostenfaktor >= 12. MD5 und SHA-1 sind sofortige Ausschlusskriterien. Symfonys PasswordHasher nutzt vernünftige Defaults. Bestätige den Algorithmus in security.yaml.

4. Alle Eingaben werden serverseitig validiert. Clientseitige Validierung ist UX, keine Sicherheit. In Symfony nutzt du Validator-Constraints auf DTOs. In Next.js API-Routes validierst du mit Zod oder einer ähnlichen Schema-Bibliothek, bevor die Daten je deine Business-Logik berühren.

5. SQL nutzt immer parametrisierte Queries oder ein ORM. Suche nach String-Verkettung in Queries:

grep -r "->query(\"SELECT.*\".*\$" src/
grep -r "db.execute(`SELECT.*\${" app/

Jeder Treffer ist ein potenzieller SQL-Injection-Vektor. KI-generierter Code produziert häufig das zweite Muster, wenn eine Entwicklerin eine Query in natürlicher Sprache beschreibt.

6. CSRF und CORS sind explizit konfiguriert. Symfony hat CSRF-Tokens in Formularen eingebaut, nutze sie. Next.js API-Routes brauchen eine explizite CORS-Policy. Der Default, alle Origins zu erlauben, ist für jedes B2B-SaaS falsch.

7. Ein Dependency-Scanner läuft bei jedem Pull Request. composer audit, npm audit, Dependabot oder Snyk. KI-generierte package.json-Dateien ziehen häufig alte, verwundbare Versionen, weil die Trainingsdaten älter sind als aktuelle CVEs.

Observability: Was du nicht sehen kannst, kannst du nicht verkaufen

Enterprise-Kunden fragen, wie du Vorfälle debuggst. "Wir lesen die Logs auf dem Server" ist keine befriedigende Antwort.

8. Strukturiertes Logging ist vorhanden. JSON-Logs über Monolog (PHP) oder Pino (Node), mit konsistentem Schema: timestamp, level, message, trace_id, user_id, tenant_id. Schlichtes console.log und error_log() zählen nicht.

9. Ein einzelner Request hat eine Correlation-ID über Services hinweg. Erzeuge sie am Edge, propagiere sie über Header (X-Request-Id), nimm sie in jede Logzeile und jeden ausgehenden API-Call auf. Ohne das kannst du einen Bug nicht durch ein verteiltes System verfolgen.

10. Fehler werden in Sentry, Rollbar oder einem Äquivalent erfasst. Unbehandelte Exceptions sollten jemanden alarmieren, nicht in einer wöchentlich rotierten Logdatei verschwinden.

11. Anwendungsmetriken sind verfügbar. Request-Rate, Error-Rate, p95/p99-Latenz, Queue-Tiefe. Prometheus ist kostenlos, Grafana Cloud hat ein großzügiges kostenloses Kontingent. Es gibt keine Entschuldigung dafür, im Blindflug zu fliegen.

12. Health-Checks existieren und bedeuten etwas. Ein /healthz-Endpunkt, der 200 zurückgibt, wenn Datenbank, Redis und kritische Upstream-Services erreichbar sind, nicht nur "der Webserver lebt".

13. Audit-Logs erfassen, wer was getan hat. Für jede Aktion, die Kundendaten verändert, protokolliere den Akteur, die Ressource, den Vorher-/Nachher-Zustand und den Zeitstempel, in einem Append-only-Store. SOC 2 verlangt das. Enterprise-Kunden fragen in der Due Diligence nach Beispiel-Audit-Log-Einträgen.

Zuverlässigkeit und Performance unter Last

Hier konzentrieren sich die Befunde aus dem Code-Quality-Audit in fast jedem Vibe-Code-Rescue, das wir durchführen.

14. Hintergrundarbeit läuft in Queues, nicht innerhalb von Request-Handlern. Symfony Messenger mit einem Redis- oder RabbitMQ-Transport. E-Mail-Versand, Dateiverarbeitung, Webhook-Zustellungen, KI-Inferenz-Aufrufe, alles asynchron, alles mit Retry und Dead-Letter-Handling.

15. Datenbank-Queries wurden profiliert. Aktiviere das Slow-Query-Log, führe EXPLAIN ANALYZE für deine zehn meistgenutzten Queries aus, füge die fehlenden Indizes hinzu. N+1-Erkennung in Doctrine:

// In dev jede Query mit Backtrace loggen
$config->setSQLLogger(new DebugStack());
// Queries pro Request zählen; alles > 30 muss untersucht werden

16. Connection Pooling ist konfiguriert. PgBouncer vor PostgreSQL, ProxySQL vor MySQL. Ohne das erreicht deine Datenbank ihr Verbindungslimit lange bevor du dein Nutzerlimit erreichst.

17. Caching hat eine explizite Policy. Was wird gecacht, wie lange und wie wird es invalidiert? Redis mit klaren TTLs schlägt "wir cachen alles für immer und starten neu, wenn es kaputtgeht".

18. Der Service degradiert sauber. Wenn Stripe langsam ist, stellt der Checkout die Belastung in eine Queue, statt in einen Timeout zu laufen. Wenn die Suche ausfällt, lädt die Produktseite trotzdem ohne Ergebnisse. Circuit Breaker in kritischen ausgehenden Pfaden.

19. Ein Lasttest wurde kürzlich durchgeführt. k6 oder Locust bei 3-facher erwarteter Spitze, gegen eine produktionsnahe Umgebung. Wer nie einen Lasttest gemacht hat, kennt seine echte Obergrenze nicht, sondern nur die Obergrenze des Laptops seiner Entwicklerin.

Datenschutz und Compliance

Nicht verhandelbar für europäisches B2B-SaaS und zunehmend überall nicht verhandelbar.

20. Backups laufen, und Wiederherstellungen wurden getestet. Tägliche automatisierte Backups der primären Datenbank mit Point-in-Time-Recovery. Entscheidend: eine dokumentierte, geprobte Wiederherstellungsprozedur. Ein ungetestetes Backup ist ein theoretisches Backup.

21. PII ist klassifiziert und minimiert. Du weißt, welche Spalten personenbezogene Daten enthalten, du verschlüsselst sie at rest, und du hast eine Aufbewahrungsrichtlinie, die Datensätze tatsächlich löscht, wenn es erforderlich ist. DSGVO Artikel 5(1)(e) ist in der EU nicht optional.

22. Ein Auftragsverarbeitungsvertrag ist bereit. Jeder Enterprise-Kunde wird einen verlangen. Halte ihn vorbereitet, kenne deine Unterauftragsverarbeiter und führe eine Liste, wohin Kundendaten fließen.

23. TLS 1.2+ überall, HSTS aktiviert. Let's Encrypt ist kostenlos, Traefik und Caddy automatisieren es. Es gibt 2026 keinen legitimen Grund, Klartext-HTTP an einen Produktionsendpunkt auszuliefern.

Deployment, Rollback und Change Management

24. Deployments sind automatisiert und wiederholbar. Eine CI/CD-Pipeline (GitHub Actions, GitLab CI, CircleCI), die Tests ausführt, ein Image baut und deployt. Keine Slack-Nachricht an die Entwicklerin mit der Bitte, zu pushen.

25. Jedes Deployment ist in unter zehn Minuten reversibel. Tagge jeden Release. Behalte das vorherige Docker-Image. Übe den Rollback, entdecke die Prozedur nicht erst während eines Ausfalls.

26. Datenbankmigrationen sind während des Rollouts abwärtskompatibel. Expand-Contract-Muster: neue Spalten hinzufügen, dual-write, Daten migrieren, alte Spalten in einem späteren Release entfernen. Doctrine Migrations unterstützt diesen Workflow, die Disziplin muss vom Team kommen.

27. Feature-Flags decken riskante Änderungen ab. LaunchDarkly, Unleash oder eine kleine Eigenimplementierung. Neue Features gehen dunkel live, werden für interne Nutzer aktiviert, dann für eine Kohorte, dann für alle. Die Fähigkeit, ein Feature ohne Deployment abzuschalten, ist eine Enterprise-taugliche Eigenschaft.

Codequalität, Dokumentation und Prozess

Die weichen Punkte, die entscheiden, ob ein zweiter Entwickler je zur Codebasis beitragen kann, ohne von vorn anzufangen.

28. Statische Analyse läuft in CI. PHPStan auf Level 5+ für PHP; tsc --noEmit mit strict: true für TypeScript; ESLint mit den empfohlenen Regeln. Die KI-generierten any-Typen und unterdrückten Warnungen werden hier gefangen.

29. Es gibt Tests, die etwas bedeuten. Nicht 100 % Coverage, sondern sinnvolle Coverage. Integrationstests für die kritischen Nutzerpfade (Registrierung, Checkout, Datenexport) und Unit-Tests für die Domänenlogik. Ein Projekt zur Legacy-Code-Optimierung beginnt fast immer damit, die Tests zu schreiben, die von Anfang an hätten existieren sollen.

30. Ein Runbook existiert für häufige Vorfälle. "Datenbank bei 90 % Disk", "Queue-Rückstau über 10.000", "Ausfall des Authentifizierungsanbieters". Je zwei Absätze, im Repo gehalten. Das erste Mal Bereitschaftsdienst um 3 Uhr nachts ist nicht der richtige Zeitpunkt, die Reaktion zu erfinden.

Wie du diese Production-Readiness-Checkliste nutzt

Versuche nicht, dreißig Lücken parallel zu schließen. Eine realistische Reihenfolge für die meisten vibe-codeten SaaS-Produkte sieht so aus: zuerst die Sicherheitspunkte, weil ein Breach das Geschäft beendet; dann Observability, weil du nicht verbessern kannst, was du nicht messen kannst; dann die Zuverlässigkeitspunkte, priorisiert nach dem, was dein Lasttest offenlegt; Compliance-Punkte getrieben von deinen konkreten Kundenverträgen; und zuletzt die Prozesspunkte, die sich über die Zeit aufsummieren, aber selten akute Vorfälle verursachen.

Ein faires internes Ziel ist, die Abschnitte Sicherheit, Observability und Zuverlässigkeit innerhalb von sechs bis acht Wochen nach einem ernsthaften Wachstumsereignis zu schließen. Das ist ein ambitionierter, aber erreichbarer Zeitplan mit einer fokussierten Senior-Entwicklerin oder einem kurzen externen Einsatz.

Enterprise-Reife ist kein einzelnes Projekt. Es ist ein Übergang von einem Modus des Bauens, schnell, explorativ, KI-gestützt, zu einem anderen Modus, der die Disziplin hinzufügt, die KI-Tools von sich aus nicht erzwingen. Die Checkliste oben ist eine Landkarte der Lücke, kein Rezept für Verzweiflung. Die meisten vibe-codeten Anwendungen, die wir sehen, sind näher an Enterprise-Reife, als ihre Gründer glauben, weil die Kern-Produktlogik oft solide ist. Was fehlt, ist die operative Hülle um diese Logik.

Wenn du auf diese Liste schaust und die Lücken in deiner eigenen Codebasis zählst, ist das nützliche Information. Der nächste Schritt ist eine strukturierte Prüfung, die die Lücken in einen priorisierten Sanierungsplan mit konkreten Aufwandsschätzungen verwandelt. Wolf-Tech bietet eine kostenlose Erstberatung für genau diese Art von Bewertung. Kontaktiere uns unter hello@wolf-tech.io oder besuche wolf-tech.io, um das Gespräch zu beginnen.