Vibe Coding in Production: Wie KI-generierte Software trägt - und souverän in Europa läuft

Inhaltsverzeichnis

• Was ist Vibe Coding? (Definition in 30 Sekunden)
• Das Wichtigste in 30 Sekunden
• Der typische Vibe-coded Stack
• Was die Daten 2026 zeigen
  • 50 % des Codes hat Sicherheitslücken (Cobalt AI 2025)
  • 69 Schwachstellen in 15 Apps (Tenzai 2025)
  • Der Enrichlead-Fall (Q4 2025)
  • CVE-Tracking durch Georgia Tech
• Warum Vibe Coding ≠ produktionsreif
  • 1. Sicherheit
  • 2. Tests
  • 3. Dependencies
  • 4. Architektur-Inkonsistenz
  • 5. Observability
  • 6. Backup und Recovery
  • 7. Kosten
• Die fünf Säulen Production-Readiness
  • Säule 1: Code-Review mit System
  • Säule 2: Patch- und Dependency-Strategie
  • Säule 3: CI/CD-Minimum
  • Säule 4: Observability
  • Säule 5: Architektur-Konsolidierung
• Der EU-souveräne Stack-Reframe
  • Hosting: Coolify statt Vercel
  • Backend: Self-Hosted Supabase, Appwrite oder PocketBase
  • LLM-Schicht
  • Identity: Authentik
  • Mail, Storage, Cache, Zahlung
• Migration-Pfad in drei Phasen
  • Phase 1 - Audit und Härtung (2 bis 4 Wochen)
  • Phase 2 - Backend-Migration (4 bis 8 Wochen)
  • Phase 3 - Hosting-Migration (2 bis 4 Wochen)
• Wann es Sinn ergibt - und wann nicht
• Fazit

Was ist Vibe Coding? (Definition in 30 Sekunden)

Vibe Coding bezeichnet das Erstellen von Software überwiegend mit KI-Assistenten wie Cursor, Claude Code, v0 oder Bolt - der Mensch beschreibt das Vorhaben in natürlicher Sprache, das Modell generiert den Code, deployt ihn, und der Nutzer prüft hauptsächlich, ob das Ergebnis sich richtig "anfühlt".

Der Begriff stammt aus dem Frühjahr 2025 (Andrej Karpathy auf X) und ist 2026 zur dominanten Arbeitsweise von Solo-Foundern und non-technical Teams geworden. Im Kern sechs Merkmale:

• Spezifikation entsteht im Prompt-Verlauf
• Architektur wird vom Modell vorgeschlagen, nicht entschieden
• Tests werden seltener ausgeführt als generiert
• Dependencies, die das Modell nennt, werden ungeprüft installiert
• Ergebnis: ein Prototyp, kein Produkt

Was hier folgt, ist der praktische Guide, wie aus diesem Prototyp tragfähige Produktiv-Software wird - und warum der typische US-Stack dabei zum Problem wird.

Das Wichtigste in 30 Sekunden

• KI-generierte Software ist kein Produkt, sondern ein Prototyp. Was funktioniert, läuft. Was bricht, bricht still.
• 24,7 bis 50 % des Vibe-coded Codes enthält ausnutzbare Sicherheitslücken (Cobalt AI 2025, Tenzai 2025).
• Der Default-Stack (Vercel + Supabase + OpenAI) ist schnell, aber ab dem ersten echten Kunden teuer und unter DSGVO heikel.
• Fünf Säulen machen vibe-coded Code produktionsreif: Review, Patches, CI/CD, Observability, Architektur.
• Für Unternehmen in Europa lohnt sich der souveräne Stack-Reframe: Coolify statt Vercel, Self-Hosted Supabase oder Appwrite statt managed Supabase, Mistral statt OpenAI.
• Migration ist machbar in 6 bis 12 Wochen, parallel zur produktiven Software.

Der typische Vibe-coded Stack

Im Mai 2026 sieht ein vibe-coded MVP fast immer gleich aus.

Ein Founder ohne tiefen Tech-Hintergrund öffnet Cursor, Claude Code, v0 oder Bolt und beschreibt, was er bauen will. Innerhalb von Stunden bis Tagen entsteht eine funktionierende Anwendung. Die Architektur wird nicht entschieden - sie wird vorgeschlagen. Standardmäßig:

• Frontend: Next.js, deployed auf Vercel
• Backend: Supabase (Postgres + Auth + Storage + Realtime)
• KI: OpenAI API direkt aus dem Frontend
• Zahlung: Stripe
• Mail: Resend
• Auth: Supabase Auth oder Clerk

Das funktioniert. Es ist reproduzierbar. Es ist beeindruckend, was in dieser Zeit möglich geworden ist.

Es ist auch - und das ist die unbequeme Wahrheit - ein Prototyp, kein Produkt. Sobald die App ihre ersten zehn echten Nutzer trifft, anfängt Geld zu sehen, oder sich vor einem deutschen Datenschutzbeauftragten erklären muss, beginnen die Probleme. Reihenweise und gleichzeitig.

Was die Daten 2026 zeigen

Die Diskussion über Vibe Coding wird oft anekdotisch geführt. Die Datenlage ist mittlerweile eindeutig.

50 % des Codes hat Sicherheitslücken (Cobalt AI 2025)

Eine Benchmark-Studie von Cobalt AI aus 2025 fand: mehr als die Hälfte des generierten Codes enthält mindestens eine ausnutzbare Sicherheitslücke. Darunter Schwachstellen, die in der konventionellen Softwareentwicklung längst als behoben galten - etwa Code, der der bekannten Log4Shell-Schwachstelle (CVE-2021-44228) ähnelt.

69 Schwachstellen in 15 Apps (Tenzai 2025)

Eine Tenzai-Studie testete 15 Anwendungen, die mit den fünf populärsten KI-Coding-Tools gebaut wurden. Ergebnis:

• 69 Schwachstellen insgesamt
• Server-Side Request Forgery in jeder einzelnen App
• Null Apps mit CSRF-Protection
• Null Apps mit Security-Headers

Die Studie testete keine Edge-Cases - das waren alles Standard-Vulnerabilities, die in OWASP-Top-10-Prüfungen seit Jahren Pflicht sind.

Der Enrichlead-Fall (Q4 2025)

Das vermutlich öffentlichkeitswirksamste Beispiel: ein Startup namens Enrichlead launchte Ende 2025 eine SaaS-App, die komplett mit Cursor gebaut wurde. Die KI hatte die gesamte Auth-Logik im Browser-Frontend platziert. Innerhalb von 72 Stunden nach Launch fanden Nutzer heraus, dass sie durch Ändern eines einzelnen Werts in der Browser-Konsole vollen Zugriff auf alle bezahlten Features bekamen. Das Projekt musste vollständig eingestellt werden.

CVE-Tracking durch Georgia Tech

Georgia Techs Vibe Security Radar monitort seit Mai 2025 CVE-Einträge, die direkt auf KI-generierten Code zurückgehen. Allein im März 2026 wurden 35 solcher CVEs verzeichnet - Tendenz steigend.

Bottom line: Wer vibe-coded App-Code ungeprüft in Produktion stellt, baut im statistischen Mittel eine angreifbare Anwendung.

Warum Vibe Coding ≠ produktionsreif

Die Diskrepanz zwischen "kompiliert und tut was" und "trägt unter realer Last und Verantwortung" wird unterschätzt. Hier die häufigsten Bruchstellen, in der Reihenfolge, in der sie typischerweise zuschlagen.

1. Sicherheit

KI-Assistenten sind großzügig mit Annahmen. In vibe-coded Apps finden sich regelmäßig:

• Service-Role-Keys im Frontend. Der Supabase-Service-Role-Key, der ohne Row-Level-Security alles darf, im Browser sichtbar. Die Datenbank, offen für jeden, der View Source drückt.
• Halluzinierte RLS-Regeln. Cursor oder Claude Code generieren Row-Level-Security-Policies, die plausibel aussehen, aber im Edge-Case nicht greifen - etwa weil auth.uid() in Server Components anders auflöst.
• CORS-Wildcards. Access-Control-Allow-Origin: *, weil das in der Entwicklung "einfacher" war.
• Fehlende Rate-Limits, insbesondere bei OpenAI-Endpunkten - ein einzelner aggressiver Bot kann die Rechnung in einer Nacht ins fünfstellige treiben.
• Hardcoded API-Keys im Repository - Cursor-Sessions kopieren sie gerne aus .env-Dateien in den Code.

2. Tests

Tests werden vorgeschlagen. Sie werden selten ausgeführt. Selbst wenn sie laufen, prüfen sie meist Trivialitäten und nicht die echten Geschäftslogik-Pfade. Vor Deployment gibt es kein Sicherheitsnetz.

3. Dependencies

KI-Assistenten halluzinieren Pakete, die nicht existieren - oder solche, die existieren, aber seit Jahren nicht mehr maintained sind. Hinzu kommt: niemand pflegt Renovate, niemand abonniert Security-Advisories, niemand prüft npm audit. Die App startet sicher und altert unsicher.

4. Architektur-Inkonsistenz

Zwischen zwei Cursor-Sessions kann sich die Architektur unbemerkt ändern. Mal heißt der Auth-Provider so, mal anders. Mal werden API-Routes über Server Actions abgewickelt, mal über REST, mal über tRPC. Der Code funktioniert - aber niemand kann ihn mehr lesen.

5. Observability

Logs werden nicht strukturiert. Fehler verschwinden in console.error. Es gibt kein Sentry, keine Metriken, kein Alerting. Wenn die App nachts kippt, merkt es niemand bis zum nächsten Support-Ticket.

6. Backup und Recovery

Supabase Pro-Plan macht Snapshots, aber kein Point-in-Time Recovery, keine Replikate, kein Failover. Wenn ein Migrations-Fehler die Produktionsdatenbank zerschießt, ist das Team ohne Plan.

7. Kosten

Der gefährlichste Failure-Mode ist nicht ein Crash, sondern eine Kostenfunktion. Vercel rechnet Edge Functions per Invocation und Bandwidth ab. Supabase rechnet Active Connections, Database Size, MAU und Realtime Messages separat ab. OpenAI tokenbasiert. Wer nicht aktiv überwacht, sieht die Kosten erst auf der Kreditkartenabrechnung.

Die fünf Säulen Production-Readiness

Wer vibe-coded Code in den produktiven Betrieb überführt, braucht nicht alles auf einmal. Aber er braucht alle fünf Säulen, in dieser Reihenfolge.

Säule 1: Code-Review mit System

Vor allem anderen muss jemand mit Senior-Erfahrung den Code lesen. Manuell. Mindestens einmal komplett. Was ein guter Review prüft:

• Auth-Pfade: Wer darf was, wo wird es geprüft, was passiert ohne Token?
• Datenfluss: Welche Daten verlassen das Backend, wer kann sie sehen?
• Error-Handling: Was passiert bei Netzwerk-Timeouts, bei Stripe-Webhook-Fehlern, bei OpenAI-Rate-Limits?
• Edge Cases: Leere Eingaben, sehr große Eingaben, Sonderzeichen, Unicode-Probleme.

Automatisierte Tools ergänzen den Review, ersetzen ihn nicht:

Werkzeug	Zweck
Semgrep	Pattern-basierte Security-Scans
CodeQL	Tiefere statische Analyse, GitHub-integriert
Snyk / Trivy	Dependency- und Container-Scans
eslint-plugin-security	JavaScript-spezifische Smells

In vibe-coded Codebases ist der erste Review oft der teuerste. Danach wird er Routine. Eine diff-basierte Review-Strategie mit Claude Code oder Cursor hat sich praxisbewährt: nicht ganze Dateien, sondern nur den PR-Diff prüfen lassen, mit fester Checklist.

Säule 2: Patch- und Dependency-Strategie

Drei Dinge etablieren, ohne weitere Diskussion:

1. Renovate oder Dependabot für automatische Dependency-Pull-Requests. Tägliche Frequenz, Auto-Merge für Patch-Versionen mit grünen Tests.
2. Container-Image-Scans mit Trivy oder Grype als Schritt im CI. Build bricht ab bei kritischen CVEs.
3. Lockfile-Hygiene. Ein package-lock.json ist im Repo, wird nicht durch zufälliges npm install zerschossen, und wird beim Merge konsequent gepflegt.

Ergänzend: Security-Advisories für die genutzten Frameworks (Next.js, Supabase, etc.) abonnieren oder per Slack-Bot in einen Channel routen. Zero-Days bei Next.js sind real und betreffen jede Standard-Vibe-App.

Säule 3: CI/CD-Minimum

Der minimale Pipeline-Zustand, ab dem produktiver Betrieb verantwortbar ist:

lint → typecheck → unit tests → integration tests
       → build → security scan → preview deploy → smoke tests
       → manual approval → production deploy → health check

Konkret bedeutet das:

• Linting & Typechecking verhindern die offensichtlichen Tipfehler.
• Tests müssen nicht 100 % Coverage haben, aber jeden Pfad zur Datenbank, zur Zahlung und zum LLM einmal durchspielen.
• Preview-Deployments für jeden Pull-Request - nicht "auf staging mergen", sondern dedicated Preview pro Branch.
• Manual Approval vor Production. Wer das nicht hat, deployed irgendwann ohne es zu wissen.
• Health-Check nach Deploy - wenn die /health-Route nicht antwortet, automatisches Rollback.

Säule 4: Observability

Drei Schichten, alle mandatorisch:

1. Strukturierte Logs. JSON-Logs mit Trace-ID. Wer das einmal hat, will nicht mehr zurück.
2. Error-Tracking. Sentry ist der Standard, Self-Hosted ist möglich. Jeder Production-Fehler landet im Dashboard, mit Stack-Trace und Userkontext.
3. Metriken & Alerting. Prometheus + Grafana + Alertmanager als Stack, Cloudwatch nur wenn AWS unvermeidbar ist. Mindestens vier Alerts: 5xx-Rate, Latenz, Database-Connection-Pool, Disk-Usage.

Ohne Observability sind Sie nicht in Produktion - Sie sind in Hoffnung.

Säule 5: Architektur-Konsolidierung

Die unsichtbarste, aber langfristig teuerste Säule. Vibe-coded Code wächst polymorph: drei Auth-Patterns, vier Datenzugriffs-Stile, zwei UI-Komponentenbibliotheken nebeneinander. Das funktioniert eine Zeit lang. Dann wird jeder Bugfix zur Detektivarbeit.

Konsolidierung heißt: einmal pro Quartal Zeit blocken, drei Patterns auswählen (eines pro Schicht), und den Rest im Zuge der nächsten Features in diese Patterns überführen. Architecture Decision Records (ADRs) dokumentieren, was entschieden wurde und warum - sodass die nächste Cursor-Session sie respektiert.

Der EU-souveräne Stack-Reframe

Bis hier ist das alles unabhängig vom Hosting. Jetzt kommt der Teil, den die meisten Vibe-Coding-Posts auslassen: wo läuft das eigentlich?

Der Default-Vibe-Stack ist optimiert für Geschwindigkeit, nicht für Souveränität. Vercel sitzt in Kalifornien, Supabase in den USA mit AWS-Backbone, OpenAI in den USA, Resend in den USA. Jeder einzelne Datenfluss kreuzt den Atlantik. Der CLOUD Act und FISA 702 geben US-Behörden Zugriff auf Daten - auch wenn diese physisch in der EU liegen - ohne richterliche Prüfung in der EU und ohne Information der Betroffenen. Schrems II hat das nicht ungültig gemacht; es hat die Risiken auf den Datenverarbeiter verlagert.

Für Unternehmen mit DSGVO-Verpflichtungen, mit Behörden- oder Healthcare-Kunden, oder mit Investoren, die gerade jetzt nach europäischer Souveränität fragen: der parallele Stack existiert. Er ist nicht mehr "weniger Komfort". Er ist anderer Komfort.

Schicht	US-Default	EU-Souverän	Kommentar
Hosting	Vercel	Coolify auf Hetzner / IONOS / OVH	Git-Push-Deploy, vergleichbare DX
Backend	Supabase	Self-Hosted Supabase / Appwrite / PocketBase	Volle Postgres + Auth + Storage
LLM	OpenAI	Mistral / OVHcloud AI Endpoints / Self-Hosted vLLM	EU-only, AVV verfügbar
Auth	Auth0 / Clerk	Authentik / Keycloak	Self-Hosted, OIDC + SAML
Mail	Resend	Postmark EU / Self-Hosted Listmonk	DSGVO-AVV
Zahlung	Stripe	Stripe (EU-Entity) / Mollie	Stripe ist mit EU-Entity ok
Cache/Queue	Vercel KV / Upstash US	Self-Hosted Redis / Upstash EU
Object Storage	Supabase Storage / S3	Hetzner Storage Box / OVH Object Storage / MinIO	S3-kompatibel

Hosting: Coolify statt Vercel

Coolify ist der ehrlichste Vercel-Ersatz. Open Source, self-hostbar auf einem Hetzner-Cloud-Server ab 5 €/Monat. Git-Push-Deploys, Preview-Branches, automatische TLS-Zertifikate, Docker-basiertes Build-System.

Was Coolify nicht leistet: das globale Edge-Network von Vercel. Für 95 % der vibe-coded Apps spielt das keine Rolle. Für Apps mit wirklich globalem Traffic kann Cloudflare oder bunny.net davor geschaltet werden.

Realistische Kostendifferenz für eine mittelgroße App: Vercel 3.000-8.000 €/Monat vs. Coolify auf Hetzner Cloud 80-250 €/Monat, plus eine Stunde Setup-Zeit pro Woche. Das ist eine 70-98-prozentige Ersparnis bei vergleichbarer Developer Experience.

Ausführlicher Vergleich folgt im Cluster-Post: Coolify als EU-Alternative zu Vercel.

Backend: Self-Hosted Supabase, Appwrite oder PocketBase

Drei Pfade, je nach Reife:

• Self-Hosted Supabase. Volle Feature-Parität mit der gehosteten Version, läuft als Docker-Compose-Stack. Aufwand: einmalig 1-2 Tage Setup, danach 2-4 Stunden Wartung pro Monat. Sinnvoll wenn die App schon tief in Supabase steckt und Migration zu vermeiden ist. Hetzner hat eine offizielle Community-Anleitung für Coolify + Self-Hosted Supabase.
• Appwrite. BaaS aus Berlin (eine deutsche GmbH). Ähnliche DX wie Supabase, eigenes Postgres dahinter, eigene Auth-Implementierung. Im Benchmark deutlich performanter pro Hetzner-Euro: auf einem 5-Euro-Server bewältigte Appwrite im Test bis zu 2.000 Nutzer pro Tag, während Supabase bei größerer Last ins Schwitzen kam.
• PocketBase. Single-Binary-BaaS, ein Go-Executable mit eingebetteter SQLite. Ideal für Solo-Founder oder kleine Apps. Skaliert nicht beliebig hoch, ist aber für 95 % der vibe-coded MVPs ausreichend und betriebsleicht.

Ausführliche Vergleiche folgen in den Cluster-Posts: Appwrite vs. Supabase und Self-Hosted Supabase auf Hetzner.

LLM-Schicht

Wer aus DSGVO- oder Souveränitäts-Gründen weg von OpenAI muss, hat 2026 endlich ernste Alternativen:

• Mistral (Frankreich) für allgemeine Chat- und Reasoning-Tasks. API-Pricing vergleichbar mit GPT-4-Niveau, AVV verfügbar, Daten bleiben in Europa.
• OVHcloud AI Endpoints für Llama, Mistral, Qwen usw., gehostet in Frankreich.
• Self-Hosted vLLM oder Ollama auf einer GPU-Maschine. Aufwand höher, dafür voll souverän und ab einem gewissen Volumen drastisch günstiger.

Für viele Apps ist eine Hybrid-Strategie sinnvoll: Sensible Daten gehen an Mistral, generische Hilfen an die günstigste API.

Identity: Authentik

Authentik ist Open Source, self-hostbar, unterstützt OIDC, SAML, MFA, Social-Logins, und kommt mit einer Admin-UI, die nicht aussieht wie aus 2009. Migration von Supabase Auth ist möglich (User-Daten exportieren, Hashes übernehmen oder Reset-Flow auslösen).

Wenn Authentik zu viel ist, ist Keycloak die etablierte Alternative. Für die meisten vibe-coded Apps ist Authentik aber moderner und schlanker.

Mail, Storage, Cache, Zahlung

Detailfragen, die schnell entschieden sind:

• Mail: Postmark hat einen EU-Endpoint mit AVV. Self-Hosted Listmonk für Newsletter. Resend hat 2025 einen EU-Endpoint angekündigt - Stand 2026 noch nicht produktionsreif.
• Object Storage: Hetzner Storage Box (günstig, simpel) oder selbst-gehostetes MinIO (S3-kompatibel, voll kontrolliert). Beides funktioniert mit jedem aws-sdk-kompatiblen Code.
• Cache/Queue: Self-Hosted Redis ist trivial. Für Queues taugt BullMQ ohne weiteres Drittsystem.
• Zahlung: Stripe ist mit EU-Entity ein akzeptabler Default. Mollie ist die niederländische Alternative mit identischer DX.

Migration-Pfad in drei Phasen

Die häufigste Befürchtung: "Wir müssen alles auf einmal umbauen." Müssen Sie nicht. Drei Phasen, parallel betreibbar.

Phase 1 - Audit und Härtung (2 bis 4 Wochen)

Hier wird der Bestand fixiert, ohne den Stack zu wechseln. Concrete Schritte:

1. Audit gegen die fünf Säulen - was fehlt komplett, was ist halb da?
2. Service-Role-Keys aus Frontend-Bundles entfernen.
3. RLS-Policies prüfen und manuell schreiben (nicht generieren lassen).
4. Renovate aktivieren, kritische Dependencies updaten.
5. Sentry oder vergleichbar einrichten.
6. Ein Smoke-Test pro Userflow.

Ergebnis: Die App läuft sicherer, ohne dass irgendetwas migriert wurde.

Phase 2 - Backend-Migration (4 bis 8 Wochen)

Dies ist der größte Schritt. Optionen:

• Supabase → Self-Hosted Supabase: geringster Code-Aufwand, höchster Betriebsaufwand. Datenbank über pg_dump/pg_restore migrieren, Auth-User exportieren und reimportieren, Storage-Buckets per Skript kopieren.
• Supabase → Appwrite: mehr Code-Änderungen, weniger Betriebsaufwand. Auth-Layer komplett neu, Datenbank-Migrationen über Appwrite-CLI.
• Supabase → PocketBase: für kleinere Apps, größter Architektur-Schnitt. Empfohlen nur für MVPs unter 10.000 Nutzern.

Während der Migration laufen alte und neue Backend-Instanz parallel, der Frontend-Build wird per Feature-Flag umgeschaltet.

Phase 3 - Hosting-Migration (2 bis 4 Wochen)

Die einfachste Phase, weil die App selbst sich kaum ändert.

1. Coolify-Server bei Hetzner / OVH provisionieren (Hetzner CCX23 ist ein guter Default).
2. Domains parallel konfigurieren (eine Subdomain für Coolify-Build, dann DNS-Cutover).
3. Build-Pipeline in Coolify einrichten (GitHub-Integration, Auto-Deploy).
4. Zertifikate via Caddy/Let's Encrypt.
5. Cutover über DNS-TTL-Reduktion und schrittweise Traffic-Verschiebung.

Realistisch ist die App nach 2 Wochen vollständig auf Coolify, mit Vercel als Notfall-Rollback für weitere 4 Wochen.

Detaillierter Walkthrough folgt im Cluster-Post: Vibe-coded App von Vercel nach Coolify migrieren.

Wann es Sinn ergibt - und wann nicht

Ehrliche Liste, weil Beratung nicht heißt, alles zu empfehlen.

Sinnvoll, wenn:

• Erster echter zahlender Kunde ist da oder kommt in den nächsten Monaten.
• Eine Series A wird vorbereitet, Tech Due Diligence absehbar.
• Cloud-Kosten haben einen vierstelligen Monatsbetrag erreicht.
• DSGVO-Anfragen kommen, AVV-Verträge werden gefragt.
• Branche ist Healthcare, Finance, Behörden, Bildung, Anwaltskanzlei.
• Team wächst - neue Devs müssen den Code verstehen.

Nicht sinnvoll, wenn:

• App ist noch in Validierung, kein Product-Market-Fit.
• Cloud-Kosten unter 200 €/Monat.
• Solo-Founder ohne kommende Compliance-Anforderungen.
• App wird in 6 Monaten möglicherweise verworfen.

In den letztgenannten Fällen ist der Default-Stack die richtige Wahl - Time-to-Market schlägt Architektur-Reinheit. Migration kann später folgen, dann gezielt, mit Plan.

Fazit

Vibe Coding hat Time-to-Market drastisch verändert. Was es nicht verändert hat: die Anforderungen an produktiven Betrieb. Wer eine vibe-coded App in den Markt bringt, hat schnell ein Produkt - aber selten eines, das ohne Härtung trägt. Die Studienlage ist eindeutig: 50 % Sicherheitslücken im Mittel, 69 von 69 möglichen Vulnerabilities in 15 getesteten Apps - das ist kein Restrisiko, das ist der Default.

Die fünf Säulen - Review, Patches, CI/CD, Observability, Architektur - sind nicht verhandelbar. Was diskutierbar ist: das Hosting darunter. Für Unternehmen in Europa, mit Compliance-Anforderungen und einem Blick auf Cloud-Kosten, ist der souveräne Stack-Reframe 2026 keine Spinnerei mehr. Coolify hat die Vercel-DX nahezu erreicht. Appwrite und Self-Hosted Supabase liefern die Backend-Schicht. Mistral und OVHcloud schließen die LLM-Lücke.

Wer sich davor scheut, weil "alles auf einmal" - der hat den Migration-Pfad noch nicht gesehen. In 6 bis 12 Wochen ist die parallele Welt da, das alte System ist Backup, und die monatlichen Kosten haben sich oft halbiert.

Wenn Sie überlegen, ob Ihr vibe-coded MVP diesen Schritt jetzt machen sollte - oder noch nicht - ist ein Triage-Call der einfachste nächste Schritt. 15 Minuten, kostenlos, ehrliche Einordnung. Wenn Sie ohnehin eine Tech Due Diligence vor sich haben oder einen Fractional CTO erwägen, lohnt das Gespräch doppelt.