Ist Ihre mit Vibe Coding gebaute App produktionsreif?

Apps, die mit Lovable, Bolt, Cursor, Replit oder v0 gebaut werden, kommen schnell zu einer funktionierenden Demo. Was die Werkzeuge auslassen, ist alles, was eine Demo nie zeigt, denn eine Demo hat einen Nutzer, keinen Angreifer, keine fehlerhaften Eingaben und keinen zweiten Deploy. Das ist die Liste, die wir durchgehen, wenn wir eine solche App auditieren. Für das meiste davon müssen Sie keinen Code lesen; wo doch, fragen Sie jemanden, der es kann.

Authentifizierung und Autorisierung

• Jede Route, die private Daten zurückgibt, prüft auf dem Server, wer angemeldet ist. Eine Prüfung im Browser ist ein Vorschlag; jeder kann die API direkt aufrufen.
• Eine geänderte ID in der URL oder im Request zeigt nicht die Datensätze eines anderen Nutzers. Das ist der häufigste Weg, auf dem Nutzer die Daten der anderen zu sehen bekommen.
• Wenn Sie Supabase oder Firebase nutzen, sind Row-Level Security oder die Security Rules für jede Tabelle aktiv und mit einem zweiten Konto getestet. Sind sie aus, kann der öffentliche Schlüssel in Ihrem Browser-Bundle alles lesen.
• Admin-Aktionen prüfen auf dem Server eine Admin-Rolle. Ein versteckter Button ist keine Berechtigung.
• Links zum Zurücksetzen des Passworts, zum Ändern der E-Mail-Adresse und für Einladungen laufen ab und funktionieren einmal. In diesen Abläufen werden Konten übernommen.

Secrets und Schlüssel

• Im Browser-Bundle liegt kein geheimer Schlüssel. Alles, was an den Browser ausgeliefert wird, ist öffentlich, und Zahlungs- oder Datenbankschlüssel dort kann jeder benutzen.
• Schlüssel liegen in Umgebungsvariablen, nicht im Repository, und die Git-Historie wurde auf alte Schlüssel geprüft. Einen Schlüssel aus dem Code zu löschen, löscht ihn nicht aus der Historie.
• Jeder Schlüssel, der je offenlag, wurde rotiert. Ein geleakter Schlüssel bleibt gültig, bis ihn jemand widerruft.

Datenmodell und Migrationen

• Sie können in einem Satz sagen, was jede Tabelle enthält. Tabellen, die Prompt für Prompt entstehen, werden zu Dubletten, die einander widersprechen.
• Die Datenbank erzwingt Beziehungen und Pflichtfelder, nicht nur die App. Hat die App einen Fehler, ist die Datenbank das Letzte, was zwischen Ihnen und fehlerhaften Daten steht.
• Schemaänderungen liegen als Migrationsdateien im Repository und werden überall auf dieselbe Weise angewendet. Eine Änderung, die in ein Produktions-Dashboard geklickt wurde, lässt sich weder prüfen noch wiederholen noch rückgängig machen.
• Backups laufen, und jemand hat eines wiederhergestellt. Ein Backup, das nie jemand wiederhergestellt hat, ist eine Hoffnung.

Eingabevalidierung und die API-Oberfläche

• Jede Eingabe wird auf dem Server auf Typ, Länge und erlaubte Werte geprüft. Die Prüfungen im Formular gelten nicht für jemanden, der die API direkt aufruft.
• Es gibt eine Liste aller Endpoints und wer sie aufrufen darf. Generierte Apps bekommen Endpoints, an deren Hinzufügen sich niemand erinnert, und die vergessenen sind die offenen.
• Endpoints, die Geld kosten oder Nachrichten versenden, haben ein Rate Limit. Ein KI-Aufruf, eine E-Mail oder eine SMS in einer Schleife ist eine Rechnung.
• Fehlermeldungen für Nutzer enthalten keine Stack Traces, Queries oder internen IDs. Diese Details sind eine Landkarte für jeden, der einen Weg hinein sucht.

Tests

• Registrierung, Zahlung und die Kernaktion haben jeweils einen automatisierten Test. Ohne sie kann die nächste Änderung unbemerkt rückgängig machen, was funktioniert.
• Tests laufen bei jeder Änderung automatisch, bevor sie gemergt wird. Ein Test, den niemand ausführt, schützt nichts.
• Ein Test beweist, dass ein Nutzer nicht an die Daten eines anderen Nutzers kommt. Es ist der Fehler, der am meisten kostet und in einer Demo am wenigsten auffällt.

Deployment, Rollback, Logging und Monitoring

• Es gibt eine Staging-Umgebung, die nicht die Produktion ist. Sonst wird jede Änderung an Ihren Nutzern getestet.
• Ein Deploy ist ein wiederholbarer Schritt aus dem Repository. Manuelle Uploads und von Hand freigegebene Previews machen jedes Release ein bisschen anders.
• Sie können in Minuten auf die vorherige Version zurückrollen und haben es einmal getan. Die Nacht, in der Sie es brauchen, ist nicht die Nacht, um es zu lernen.
• Fehler in der Produktion werden dort protokolliert, wo Sie sie sehen, mit genug Kontext, um sie nachzustellen. „Bei einem Kunden ist es kaputtgegangen“ ist kein Bug-Report.
• Jemand wird alarmiert, wenn die App ausfällt oder die Fehler sprunghaft steigen. Ohne das sind Ihre Nutzer Ihr Monitoring.

Abhängigkeiten

• Ein Lockfile ist committet. Ohne Lockfile können zwei Installationen desselben Codes verschiedene Bibliotheken ausführen.
• Ein Dependency-Audit zeigt keine bekannten kritischen Schwachstellen. Der größte Teil des Codes, den Sie ausliefern, ist Code, den Sie nicht geschrieben haben.
• Jedes Paket wird genutzt, und keines erledigt eine Aufgabe, die ein anderes schon erledigt. Generierter Code fügt pro Prompt Pakete hinzu, und jedes ist etwas, das aktualisiert und dem vertraut werden muss.

Dokumentation und wer den Code lesen kann

• Der Code liegt in einem Repository, das Ihnen gehört, nicht nur im Workspace des Werkzeugs. Wenn das Konto oder das Werkzeug wegfällt, sollte das Produkt nicht mit wegfallen.
• Eine README sagt, wie man es lokal startet, welche Umgebungsvariablen es braucht und wie man es deployt. Der nächste Entwickler, oder Sie in sechs Monaten, fängt dort an.
• Jemand anderes als die Person, die die Prompts geschrieben hat, kann erklären, wie ein Request durch die App läuft. Wenn niemand es erklären kann, kann es niemand sicher ändern.

Wie das Audit seine Befunde ordnet

Dreißig Punkte sind nicht alle gleich wichtig, und sie in der Reihenfolge dieser Liste zu beheben, wäre die falsche Reihenfolge. Das Audit ordnet die Befunde danach, was zuerst kaputtgeht. Ganz oben steht alles, was heute Daten oder Geld abfließen lassen kann: offenliegende Schlüssel, offene Endpoints, fehlende Validierung, kaputte Authentifizierung und Berechtigungen und die Fehler, auf die Ihre Nutzer schon stoßen. Danach kommt, was bei der nächsten Änderung oder den nächsten hundert Nutzern kaputtgeht: keine Tests, kein Staging, kein Rollback, ein Datenmodell, das das nächste Feature nicht trägt. Zuletzt kommt, was das Team bremst, ohne bisher jemandem zu schaden: Abhängigkeiten, Dokumentation, Code, den niemand lesen kann.

Was der schriftliche Bericht enthält

Das Audit ist kostenlos und schriftlich und liegt innerhalb von 24 Stunden vor. Es umfasst die Architektur, das Datenmodell, Authentifizierung und Berechtigungen, Secrets, Abhängigkeiten, Testabdeckung und Deployment. Jeder Befund ist danach geordnet, was zuerst kaputtgeht. Am Ende steht eine klare Antwort zu Refactoring oder Neubau und was beides kostet: Stabilisierung ab $10k, eine vollständige Rettung $20k bis $50k, bepreist nach dem, was das Audit gefunden hat, statt nach Gefühl. Der Bericht gehört Ihnen, ob Sie uns beauftragen oder nicht.

Wenn Sie die meisten der dreißig selbst abhaken konnten, brauchen Sie uns vielleicht nicht. Wenn Sie die Hälfte nicht beantworten konnten, ist das der Befund.