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 – keine Abrechnung mit bestimmten Tools.

Denn „deployed” und „produktionsreif” sind zwei verschiedene Dinge. In dieser Lücke verlieren Gründer Kunden, Daten – und gelegentlich ihr Unternehmen.

Auch das ist keine Kritik an einem einzelnen Tool, sondern ein Raster, um nüchtern einzuordnen, wo man steht – und welcher Schritt als Nächstes ansteht, wenn die Validierungsphase zu Ende geht.

Was Vibe-Coding-Tools wirklich gut können

Eines vorweg: Für bestimmte Zwecke sind diese Tools wirklich stark. Prototyping, Hypothesentests, Investor-Demos, Concierge-MVPs, Landing-Page-Experimente – überall dort, wo es ums Lernen geht und nicht um Betriebsstabilität. Für einen Prototyp gelten andere Massstäbe als für ein Produktivsystem – und diese Anforderungen erfüllen Vibe-Coding-Tools problemlos.

Die eigentliche Frage ist, was danach kommt.

Die 6 Fragen zur Produktionsreife

Hält die App der zehnfachen Last stand?

Vibe-Coding-Plattformen sind für Entwicklung und moderate Nutzung gedacht. Wächst der Traffic, läuft man schnell in Speicherlimits, CPU-Drosselung oder Cold-Start-Probleme – die App wird langsam oder fällt aus. Entscheidender ist: In Vibe-Coded-Apps fehlen häufig die Bausteine, die Skalierung überhaupt erst möglich machen – Connection-Pooling für die Datenbank, Caching, effiziente Queries, Hintergrund-Jobs.

Ehrliche Gegenprobe: Wenn die Spitze heute bei 20 gleichzeitigen Nutzern liegt – was passiert bei 200? Wurde das je getestet? Weiss man überhaupt, wie sich die App unter Last verhält? Lautet die Antwort zweimal Nein, ist das eine Lücke, die geklärt gehört, bevor zahlende Kunden auf Zuverlässigkeit angewiesen sind.

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

Produktivsysteme fallen aus – die Frage ist nicht ob, sondern wann. Entscheidend ist, wie schnell man davon erfährt und wie schnell sich das beheben lässt.

Die meisten Vibe-Coding-Plattformen liefern weder belastbares Monitoring noch Alerting oder automatische Wiederherstellung. Stürzt die App mitten in der Nacht ab, erfährt man es im Zweifel erst, wenn am nächsten Morgen die erste Kundenmail reinkommt. Für einen Prototyp mag das reichen. Für ein Produkt, auf das jemand zahlt und das im Tagesgeschäft gebraucht wird, nicht.

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

Das ist der Punkt, der Gründern am häufigsten auf die Füsse fällt. Vibe-Coded-Apps setzen meist auf eine Mischung aus plattformeigenen Speichern und externen Datenbanken – und Backup und Recovery sehen für jede Kombination anders aus. Oft weiss schlicht niemand genau, wie das Ganze im Ernstfall funktioniert.

Die entscheidenden Fragen: Fällt die Hosting-Plattform heute aus und die Datenbank ist nicht erreichbar – was passiert mit den Kundendaten? Gibt es ein Backup? Wo liegt es? Wie aktuell ist es? Wie lange dauert eine Wiederherstellung? Wer darauf keine konkreten Antworten hat, hat schlicht keine tragfähige Datenstrategie für den Betrieb.

Für Gründer in Europa kommt das Thema DSGVO dazu: In welchem Land werden die Kundendaten gespeichert? Sind die nötigen Auftragsverarbeitungsverträge unterschrieben?

Ist die Authentifizierung wirklich sicher?

Authentifizierung haben die meisten Vibe-Coded-Apps – Nutzer loggen sich ein, Passwörter werden irgendwo gespeichert. An der Autorisierung hapert es dann häufiger: also an der Logik, die bestimmt, welcher Nutzer auf welche Daten zugreifen darf, welche Aktionen eine Rolle ausführen kann und was passiert, wenn jemand auf den Account einer anderen Person zugreifen will.

Gut möglich, dass die Vibe-Coded-Auth den Normalfall sauber abdeckt, die Ausnahmen aber nicht: Session-Tokens werden nicht wirklich validiert, Autorisierungsprüfungen fehlen bei API-Endpunkten und existieren nur im UI, Ablaufzeiten von Tokens werden nicht korrekt gehandhabt. Bei Supabase-basierten Apps gilt ausserdem: Automatisch erzeugte Row-Level-Security-Policies decken selten alle nötigen Fälle ab – falsch konfiguriertes RLS zählt in der Praxis zu den häufigsten Ursachen für Datenlecks. Policies müssen geprüft und getestet werden, nicht bloss generiert.

Die Auth- und Autorisierungslogik sollte von jemandem geprüft werden, der weiss, worauf zu achten ist – bevor fremde Nutzer mit Zahlungsdaten angelegt werden.

Wie schnell kannst du einen Fix deployen?

Im Betrieb müssen Bugs schnell raus – weil ein Kunde feststeckt oder weil ein Sicherheitsproblem aktiv ausgenutzt wird. Wie stabil ist also der Deployment-Prozess? Gibt es einen Rollback, wenn ein neues Deployment Ärger macht? Existiert eine Staging-Umgebung, in der Fixes vor dem Go-Live getestet werden können?

Vibe Coding hat das Deployment so stark vereinfacht, dass es sich nach einer Stärke anfühlt. Die Kehrseite: „Einfach zu deployen” heisst oft auch „einfach, kaputten Code direkt produktiv zu schalten” – ohne die Schutznetze, die eine ordentliche Deployment-Pipeline einzieht.

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

Diese Frage gehört dazu, weil die meisten Gründer sie überspringen – und weil die anderen fünf erst dann sinnvoll werden. Wer eine Idee validiert, braucht Verhaltensdaten. Nicht nur „wie viele haben sich registriert”, sondern was sie tatsächlich gemacht haben, wo sie ausgestiegen sind, was sie ignoriert haben.

Vibe-Coding-Tools richten das nicht von selbst ein. Ein einfaches Setup mit Google Analytics 4 und dem Google Tag Manager liefert Seitenaufrufe und Session-Daten. Microsoft Clarity oder LogRocket ergänzen das um Session-Recordings und Heatmaps – man sieht echten Nutzern bei der Bedienung zu, erkennt, wo sie zögern, was sie klicken und wo sie etwas erwarten, das nicht passiert.

Der Produktivitäts-Aspekt dahinter: Wer auf Basis seiner Validierungsdaten eine Go/No-Go-Entscheidung treffen will, braucht Zahlen, denen er vertraut. Also Analytics sauber aufsetzen – inklusive Custom Events für die wichtigsten Aktionen im Produkt – bevor ernsthaft Traffic auf die App gelenkt wird. Eine App, die man nicht messen kann, lässt sich auch nicht wirklich validieren.

Was die Ergebnisse bedeuten

Wer drei oder mehr dieser Fragen nicht sauber beantworten kann, hat einen Prototyp – und genau das soll ein Prototyp auch sein: schnell gebaut, gut genug zum Testen, aber eben nicht für den Produktivbetrieb gehärtet.

Das heisst nicht, dass das eingesetzte Tool falsch war. Es heisst, dass die App noch nicht tragfähig genug ist, um im Arbeitsalltag eines zahlenden Kunden eine zentrale Rolle zu spielen. Zwischen „wir probieren das gerade aus”, wo ein paar Ecken und Kanten akzeptiert werden, und „wir zahlen dafür, weil unser Geschäft daran hängt”, wo jede Ecke einen realen Preis hat, liegt ein deutlicher Unterschied.

Was nach Vibe Coding kommt

Die Antwort lautet nicht „klassische Agentur beauftragen und alles neu aufsetzen”. Interessanter ist Agentic Coding auf einem Produktiv-Stack – KI-Agenten wie Cursor oder Claude Code in einer echten Engineering-Umgebung, mit ordentlicher Infrastruktur, Versionskontrolle, CI/CD und einem Datenbankschema, das für den Dauerbetrieb ausgelegt ist.

Das ist ein grundlegend anderer Ansatz als Vibe Coding – und auch als klassische Entwicklung. Der Geschwindigkeitsvorteil KI-gestützter Arbeit bleibt, die Betriebsqualität ist von Anfang an gegeben. Ein kleines Team mit Agentic Coding schafft heute das, wofür früher ein deutlich grösseres Team nötig war – und das Ergebnis ist stabil, weil die Engineering-Entscheidungen von Menschen getroffen werden und nicht aus einem Prompt fallen.

Wann migrieren?

Der Auslöser für eine Migration ist weder eine bestimmte Nutzerzahl noch ein Umsatzwert. Es ist der Moment, in dem die Kosten eines Ausfalls die Kosten ordentlicher Entwicklung übersteigen.

Drei Situationen verschieben diese Rechnung regelmässig: wenn Kunden zahlen und entsprechend Zuverlässigkeit erwarten; wenn sensible Daten im Spiel sind, die unter DSGVO oder ähnliche Vorschriften fallen; und wenn Verfügbarkeit Teil des Geschäftsmodells ist.

Jedes dieser drei Szenarien spricht dafür, eine echte Produktiv-Infrastruktur aufzuziehen, statt das bestehende Setup zu flicken. Ein Neuaufbau ist teuer – aber erfahrungsgemäss deutlich günstiger als die Summe aus Kundenverlust, Datenpannen und Reputationsschaden, wenn man ein echtes Geschäft auf einer Prototyp-Infrastruktur fährt.

Erfahrungswert aus Projekten (kein Festpreis): Eine Migration auf einen echten Stack nach längerer Zeit auf einer Vibe-Plattform liegt oft beim Mehrfachen dessen, was „von Anfang an richtig bauen” gekostet hätte – abhängig von Datenmodell und Traffic. Der Wert der Validierung kann diese Mehrkosten rechtfertigen, aber rechnen muss man beides.

Produktion statt Flicken?

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