Ist deine Vibe-Coded App produktionsreif?

Du hast eine URL, einen Login und erste Zahlen – für viele Validierungstests völlig ausreichend. Sobald Geld oder Vertrauen auf dem Spiel stehen, gelten andere Massstäbe: Last, Wiederherstellung, Autorisierung, reproduzierbare Deployments. Die folgenden sechs Fragen sind ein Selbstcheck – kein Angriff auf bestimmte Tools.

Denn „deployed” und „produktionsreif” sind nicht dasselbe. Die Lücke dazwischen ist der Ort, an dem Gründer Kunden verlieren, Daten verlieren – und gelegentlich ihr Unternehmen.

Das ist keine Kritik an einem bestimmten Tool. Es ist ein Rahmen, um ehrlich einzuschätzen, wo man steht – und zu verstehen, was der nächste Schritt bedeutet, wenn man bereit ist, die Validierungsphase hinter sich zu lassen.

Was Vibe-Coding-Tools wirklich gut können

Vorab: Diese Tools sind für bestimmte Dinge wirklich exzellent. Prototyping, Hypothesentests, Investor-Demos, Concierge-MVPs, Landing-Page-Experimente – alles, wo das Ziel Lernen ist, nicht Zuverlässigkeit. Der Massstab für Prototyp-Qualität ist ein anderer als für Produktions-Qualität, und Vibe-Coding-Tools erfüllen den Prototyp-Massstab komfortabel.

Die Frage ist, was danach kommt.

Die 6 Fragen zur Produktionsreife

Hält die App der zehnfachen Last stand?

Vibe-Coding-Plattformen sind auf Entwicklung und leichte Nutzung ausgelegt. Bei wachsendem Traffic kann man auf Speicherlimits, CPU-Drosselung oder Cold-Start-Probleme stossen, die die App langsam oder nicht verfügbar machen. Wichtiger: Vibe-Coded Apps fehlen oft die Architekturmuster, die Skalierung erst ermöglichen – Datenbankverbindungs-Pooling, Caching, effiziente Queries, Background-Job-Processing.

Ehrlicher Test: Wenn der aktuelle Peak bei 20 gleichzeitigen Nutzern liegt – was passiert bei 200? Wurde das getestet? Gibt es überhaupt Sichtbarkeit ins Verhalten der App unter Last? Wenn beide Antworten Nein sind, ist das eine Lücke, die man verstehen sollte, bevor man zahlenden Kunden Zuverlässigkeit verspricht.

Was passiert, wenn die App um 2 Uhr nachts abstürzt?

Produktionssysteme versagen – nicht ob, sondern wann. Die Frage ist, wie schnell man davon erfährt und wie schnell man es beheben kann.

Die meisten Vibe-Coding-Plattformen bieten kein robustes Monitoring, keine Alarmierung und keine automatische Wiederherstellung. Stürzt die App nachts ab, erfährt man es womöglich erst, wenn sich ein Kunde am nächsten Morgen meldet. Für einen Prototyp ist das akzeptabel. Für ein Produkt, für das jemand bezahlt und das er für sein Geschäft braucht, nicht.

Wo leben die Daten deiner Nutzer – und sind sie gesichert?

Das ist die Frage, die am häufigsten Schmerz verursacht. Vibe-Coded Apps nutzen oft eine Mischung aus plattformverwalteten Speichern und Dritt-Datenbanken, und die Backup- und Recovery-Geschichte ist für jede Kombination anders – und oft unklar.

Die wichtigen Fragen: Wenn die Hosting-Plattform heute ausfiele und die Datenbank nicht verfügbar wäre – was würde mit den Kundendaten passieren? Gibt es ein Backup? Wo liegt es? Wie aktuell ist es? Wie lang würde die Wiederherstellung dauern? Wer diese Fragen nicht mit konkreten Antworten beantworten kann, hat keine produktionsreife Datenstrategie.

Für europäische Gründer kommt die DSGVO-Dimension hinzu: In welchem Land werden die Kundendaten gespeichert? Sind die erforderlichen Datenverarbeitungsverträge abgeschlossen?

Ist die Authentifizierung wirklich sicher?

Viele Vibe-Coded Apps haben Authentifizierung – Nutzer können sich einloggen, Passwörter werden gespeichert. Weniger haben ordentliche Autorisierung: die Logik, die bestimmt, welcher Nutzer auf welche Daten zugreifen kann, welche Operationen jede Rolle ausführen darf, was passiert, wenn jemand auf das Konto einer anderen Person zugreifen will.

Könnte es sein, dass die Vibe-Coded Auth den Happy Path korrekt behandelt und die Edge Cases nicht? Session-Tokens werden möglicherweise nicht richtig validiert. Autorisierungs-Checks fehlen bei API-Endpunkten und sind nur in der UI vorhanden. Token-Ablauf wird nicht korrekt behandelt. Bei Supabase-basierten Apps: Automatisch generierte Row-Level-Security-Policies decken oft nicht alle erforderlichen Fälle ab – falsch konfiguriertes RLS ist in der Praxis eine häufige Ursache für Datenlecks. Policies müssen geprüft und getestet werden, nicht nur generiert.

Die Auth- und Autorisierungslogik sollte von jemandem reviewt werden, der weiss, wonach er sucht – bevor Fremde mit Zahlungsinformationen ongeboardet werden.

Wie schnell kannst du einen Fix deployen?

In der Produktion müssen Bugs schnell behoben werden – manchmal weil ein Kunde blockiert ist, manchmal wegen eines aktiven Sicherheitsproblems. Wie sicher ist der Deployment-Prozess? Gibt es einen Rollback-Mechanismus, wenn ein neues Deployment Probleme einführt? Eine Staging-Umgebung, um Fixes zu testen, bevor sie live gehen?

Vibe Coding vereinfacht das Deployment so weit, dass es sich wie eine Stärke anfühlt. Das Risiko: „Einfach zu deployen” kann bedeuten „einfach, kaputten Code in die Produktion zu bringen” – ohne die Absicherungen, die eine echte Deployment-Pipeline bietet.

Misst du überhaupt, was Nutzer in der App tun?

Diese Frage kommt hinzu, weil sie die meisten Gründer überspringen – und weil sie die anderen fünf erst sinnvoll macht. Wer eine Idee validiert, braucht Verhaltensdaten. Nicht nur „wie viele Nutzer haben sich angemeldet”, sondern was sie tatsächlich getan haben, wo sie abgebrochen sind, was sie ignoriert haben.

Vibe-Coding-Tools richten das nicht automatisch ein. Ein einfaches Google Analytics 4 + Google Tag Manager Setup liefert Seitenaufrufe und Session-Daten. Microsoft Clarity oder LogRocket liefern Session-Recordings und Heatmaps – man kann buchstäblich dabei zusehen, wie echte Nutzer die App bedienen, wo sie zögern, was sie anklicken und wo sie etwas erwarten, das nicht passiert.

Die Produktionsreife-Dimension: Wer eine Go/No-Go-Entscheidung auf Basis seiner Validierungsdaten treffen will, braucht verlässliche Daten. Analytics richtig einrichten – inklusive Custom Events für die wichtigsten Aktionen im Produkt – bevor ernsthafter Traffic auf die App geleitet wird. Eine App, die man nicht messen kann, ist eine App, die man nicht wirklich validieren kann.

Was die Ergebnisse bedeuten

Wenn die App drei oder mehr dieser Fragen nicht besteht, ist das für einen Prototyp normal. Genau das sollte ein Prototyp sein: schnell gebaut, gut genug zum Testen, noch nicht für den Produktionseinsatz gehärtet.

Das bedeutet nicht, dass das verwendete Tool falsch war. Es bedeutet, dass die App noch nicht das Fundament des Workflows eines zahlenden Kunden sein kann. Es gibt einen erheblichen Unterschied zwischen „wir testen das gerade” – wo raue Kanten erwartet werden – und „wir zahlen dafür, weil unser Geschäft davon abhängt” – wo raue Kanten reale Kosten haben.

Was nach Vibe Coding kommt

Die Antwort ist nicht „eine traditionelle Entwicklungsagentur beauftragen und alles von Grund auf neu bauen”. Die interessantere Antwort ist Agentic Coding auf einem Produktions-Stack – KI-Agenten wie Cursor oder Claude Code in einer echten Engineering-Umgebung, mit echter Infrastruktur, Versionskontrolle, CI/CD und einem Datenbankschema, das auf Bestand ausgelegt ist.

Das ist grundlegend anders als sowohl Vibe Coding als auch traditionelle Entwicklung. Der Geschwindigkeitsvorteil KI-gestützter Entwicklung bleibt erhalten. Die Produktionsqualität ist von Anfang an da. Ein kleines Team, das Agentic Coding einsetzt, kann das leisten, was früher ein viel grösseres Team erforderte – und der Output ist solide, weil die Engineering-Entscheidungen von Menschen getroffen werden, nicht von einem Prompt generiert.

Wann migrieren?

Der Migrations-Trigger ist keine bestimmte Nutzerzahl oder ein Umsatzschwellenwert. Es ist der Moment, wenn die Kosten des Scheiterns die Kosten ordentlicher Entwicklung übersteigen.

Drei Situationen verschieben diese Rechnung regelmässig: wenn Kunden zahlen und Zuverlässigkeit erwarten, wenn sensible Daten verarbeitet werden, die der DSGVO oder ähnlichen Vorschriften unterliegen, und wenn Verfügbarkeit tragend für das Geschäftsmodell ist.

An jedem dieser Punkte ist der richtige Schritt, von Anfang an eine Produktionsinfrastruktur aufzubauen, statt das bestehende Setup zu flicken. Ein kompletter Neuaufbau ist teuer – typischerweise aber erheblich weniger teuer als die Kombination aus Kundenverlust, Datenvorfällen und Reputationsschäden, die entstehen, wenn man ein Produktionsgeschäft auf Prototyp-Infrastruktur betreibt.

Heuristik aus Projekten (kein Festpreis): Eine Migration zu einem echten Stack nach langer Zeit auf einer Vibe-Plattform liegt oft beim Mehrfachen der Kosten von „von Anfang an richtig bauen”, stark abhängig von Datenmodell und Traffic. Der Validierungswert kann die Migrationskosten durchaus überwiegen – aber beides sollte explizit gerechnet werden.

Produktion statt Flicken?

Discovery Call – wir reviewen Auth, Daten und Deployment und schlagen Agentic Coding auf einem Stack vor, der zu deinem Risikoprofil passt.