Wie du einen KI-Prototyp in den Produktivbetrieb bringst

Um einen KI-Prototyp in den Produktivbetrieb zu bringen, schließt du die Lücke zwischen „Es funktioniert, wenn ich es ausprobiere“ und „Es funktioniert weiter, wenn andere es benutzen“. In der Praxis bedeutet das fünf Dinge: die wichtigsten Abläufe bei jeder Änderung testen, festlegen, wer was sehen und ändern darf, sicherstellen, dass du von Fehlern erfährst, bevor deine Nutzer sie dir melden, die Daten sichern und beweisen, dass du sie wiederherstellen kannst, und die App auf dem Handy schnell genug halten. Nichts davon erfordert einen Neuaufbau. Es ist eine Checkliste, die du gemeinsam mit derselben KI abarbeitest, die den Prototyp gebaut hat.

Prototyp vs. Produktivbetrieb: Was sich wirklich ändert

Ein Prototyp hat einen sorgfältigen Nutzer: dich. Du weißt, welche Knöpfe du drücken musst, gibst sinnvolle Eingaben ein, und wenn etwas kaputtgeht, zuckst du mit den Schultern und bittest die KI um eine Korrektur. Im Produktivbetrieb gibt es viele unvorsichtige Nutzer, einige neugierige und gelegentlich einen feindseligen. Der Code muss nicht „Enterprise“ werden; er muss mit den Situationen umgehen, denen ein Prototyp nie begegnet.

Bereich	Prototyp	Produktivbetrieb
Daten	Beispielzeilen, leicht zurückzusetzen	Echte Kundendaten, die du nicht verlieren darfst
Nutzer	Du, als Admin angemeldet	Viele Konten mit unterschiedlichen Rechten
Eingaben	Was du tippst	Leere Felder, riesige Dateien, seltsame Zeichen, Skripte
Fehler	Du siehst sie in der Vorschau	Passieren, während du schläfst
Änderungen	Bearbeiten und anschauen	Ändern, ohne das zu brechen, worauf Menschen sich verlassen
Geheimnisse	Alles geht in einen Testschlüssel	Live-Schlüssel, die Geld kosten, wenn sie abfließen

Der Rest dieses Guides geht jede Zeile durch.

Schritt 1: Den Umfang festlegen und die wichtigsten Abläufe notieren

Bevor du etwas absicherst, entscheide, was Version eins ist. Liste die drei bis sechs Abläufe auf, die am wichtigsten sind — zum Beispiel „registrieren, Projekt anlegen, Teammitglied einladen, bezahlen“. Diese werden dein Testskript, deine Überwachungsziele und die Dinge, die du nach jeder Änderung prüfst.

Alles, was nicht auf der Liste steht, wird entweder gestrichen oder klar als Beta gekennzeichnet. Vier verlässliche Abläufe sind weit einfacher zu erreichen als vierzehn.

Schritt 2: Wie ein Fremder testen, dann wiederholbar machen

KI-Builder sind gut darin, Code zu erzeugen, der auf dem Idealpfad funktioniert. Produktionsprobleme entstehen auf den unglücklichen Pfaden. Teste jeden wichtigen Ablauf mit:

Fehlerhaften Eingaben: leere Pflichtfelder, ein Name mit 5.000 Zeichen, eine E-Mail ohne @, eine negative Menge, ein Datum in der Vergangenheit.
Neuladen und Zurück-Button: lade die Seite mitten im Checkout neu; drücke nach dem Absenden eines Formulars „Zurück“. Wird etwas doppelt angelegt?
Zwei Tabs, zwei Nutzer: melde dich mit zwei verschiedenen Konten an und versuche, die Seiten des anderen zu öffnen, indem du die ID in der URL änderst.
Langsam und klein: ein Bildschirm in Handygröße und eine gedrosselte Verbindung (die Entwicklertools des Browsers können das simulieren).
Leere Zustände: ein brandneues Konto ohne Daten. Prototypen werden oft mit Beispieldaten gebaut und wirken ohne sie kaputt.

Mach die Prüfung dann wiederholbar. Behalte mindestens eine schriftliche Checkliste und führe sie vor jeder Veröffentlichung aus. Besser noch: Bitte die KI, automatisierte Tests für die wichtigsten Abläufe zu schreiben:

Füge automatisierte End-to-End-Tests für diese Abläufe hinzu: Registrierung mit E-Mail, Projekt anlegen, einen zweiten Nutzer einladen und den Checkout im Stripe-Testmodus abschließen. Ergänze außerdem Tests, die bestätigen, dass ein Nutzer das Projekt eines anderen Nutzers nicht ansehen oder bearbeiten kann, indem er die URL ändert.

Tests, die beweisen, dass ein Nutzer etwas nicht tun kann, fehlen Prototypen am häufigsten.

Schritt 3: Sicherheitsgrundlagen, die Prototypen auslassen

Die meisten Sicherheitsprobleme in mit KI gebauten Apps sind nicht exotisch. Es fehlen einfach Prüfungen. Geh diese Liste durch und lies die ausführlichere Sicherheits-Checkliste für mit KI gebaute Apps:

Berechtigungen auf dem Server. Einen Button zu verstecken ist keine Sicherheit. Jede Anfrage, die Daten liest oder ändert, muss auf dem Server prüfen, ob der angemeldete Nutzer das darf. Wenn deine App eine Datenbank mit Zeilenregeln nutzt, prüfe, ob sie aktiviert und getestet sind.
Geheimnisse aus dem Browser heraus. API-Schlüssel für Zahlungen, E-Mail oder KI-Anbieter gehören in serverseitige Umgebungsvariablen, niemals in Frontend-Code. Wenn du nicht sicher bist, was das bedeutet, lies was Umgebungsvariablen und Geheimnisse sind.
Validierung auf dem Server. Der Browser lässt sich umgehen, also wiederhole jede wichtige Prüfung auf dem Server.
Anmeldung richtig umgesetzt. Nutze eine gut getestete Authentifizierungsbibliothek oder einen Dienst statt selbstgebauter Passwortspeicherung. Unser Guide zu Anmeldung in deiner App beschreibt die Optionen.
Ratenbegrenzung bei Anmeldung, Registrierung, Passwort-Zurücksetzen und allem, was E-Mails verschickt oder eine kostenpflichtige API aufruft.
Freundliche Fehlermeldungen. Nutzer sollen „Etwas ist schiefgelaufen“ sehen; die Details gehen in deine Logs, nicht auf den Bildschirm.
Alles Abgeflossene rotieren. Wenn ein Live-Schlüssel jemals in einen Chat, einen Commit oder einen Screenshot kopiert wurde, ersetze ihn beim Anbieter.

Ein Prompt, der viel Boden auf einmal abdeckt:

Prüfe diese App auf Sicherheit für den Produktivbetrieb. Kontrolliere, dass jede API-Route verifiziert, dass der angemeldete Nutzer den Datensatz besitzt, den sie liest oder ändert, dass keine geheimen Schlüssel an den Browser gesendet werden, dass Eingaben serverseitig validiert werden und dass Anmeldung und Passwort-Zurücksetzen ratenbegrenzt sind. Liste zuerst auf, was du findest, bevor du etwas änderst.

Wenn du zuerst eine Liste verlangst, siehst du die Probleme und entscheidest über die Reihenfolge, statt eine riesige Änderung auf einmal zu bekommen.

Schritt 4: Wissen, wenn etwas kaputtgeht — Logging und Überwachung

In der Vorschau siehst du Fehler, sobald sie passieren. Im Produktivbetrieb muss die App dir Bescheid geben. Drei Ebenen, von am günstigsten zu am nützlichsten:

Server-Logs. Stelle sicher, dass Fehler mit genügend Kontext protokolliert werden, um sie nachzustellen: welche Route, welche Nutzer-ID (nicht Passwort oder Kartendaten), welche Form der Eingabe. Bitte die KI um strukturiertes Logging, wenn die App nur auf die Konsole schreibt.
Fehlerverfolgung. Ein Dienst wie Sentry oder ein ähnliches Tool erfasst Ausnahmen im Frontend und im Backend, gruppiert sie und schickt dir eine E-Mail. Für eine kleine App reichen oft die kostenlosen Tarife dieser Dienste; prüfe die aktuellen Limits auf deren Websites.
Verfügbarkeitsprüfungen. Ein externer Dienst lädt alle paar Minuten deine Startseite und eine wichtige API-Route und alarmiert dich, wenn sie ausfallen. So fängst du Probleme ab, durch die die App gar nicht mehr loggt.

Eine Gewohnheit kommt hinzu: Öffne nach jeder Veröffentlichung die Live-App und führe deine Checkliste für die wichtigsten Abläufe auf der echten URL aus, nicht nur in der Vorschau.

Schritt 5: Backups und ein Weg zurück

Zwei verschiedene Dinge müssen geschützt werden, und sie werden leicht verwechselt.

Code. Halte das Projekt in der Versionsverwaltung, damit jede Änderung rückgängig gemacht werden kann. Viele KI-Builder speichern Checkpoints deiner Dateien; eine Synchronisation mit einem Git-Repository gibt dir zusätzlich eine Kopie außerhalb des Builders.
Daten. Ein Zurücksetzen des Codes setzt die Datenbank nicht zurück. Eine fehlerhafte Migration oder ein fehlerhafter Lösch-Button kann Zeilen vernichten, die kein Code-Checkpoint zurückbringt.

Richte für die Daten regelmäßige Backups ein, die außerhalb des Hostings der App gespeichert werden. Für eine Postgres-Datenbank ist ein geplantes pg_dump auf separatem Speicher der übliche Weg, und viele verwaltete Datenbank-Hosts bieten automatische Backups oder Point-in-Time-Wiederherstellung. Dann folgt der Schritt, den die meisten auslassen: Spiele ein Backup in eine Test-Datenbank ein und prüfe, ob die Daten da sind.

Bitte die KI außerdem, riskante Aktionen sicherer zu machen: einen Bestätigungsschritt für Löschvorgänge und „Soft Delete“ (Zeilen als gelöscht markieren statt sie zu entfernen) für alles, was Nutzer vielleicht zurückhaben wollen.

Schritt 6: Performance, die auf dem Handy standhält

Prototypen fühlen sich schnell an, weil du der einzige Nutzer bist und der Datenbestand winzig ist. Vor dem Launch:

Mit realistischen Datenmengen laden. Bitte die KI, ein paar tausend Zeilen einzuspielen und zu prüfen, welche Seiten langsam werden. Listen brauchen meist Paginierung, und die Datenbank braucht meist Indizes auf den Spalten, nach denen du filterst und sortierst.
Bilder verkleinern. Übergroße Bilder sind der häufigste Grund für langsam ladende Seiten. Bitte um skalierte, komprimierte Bilder und verzögertes Laden unterhalb des sichtbaren Bereichs.
Messen. Führe Lighthouse in den Entwicklertools von Chrome auf der Live-URL im Mobilmodus aus. Googles Core Web Vitals sind ein sinnvolles Ziel: Largest Contentful Paint innerhalb von 2,5 Sekunden, Interaction to Next Paint von 200 ms oder weniger und Cumulative Layout Shift von 0,1 oder weniger.
Auf „Aufwach“-Verzögerungen achten. Hosting, das im Leerlauf schläft, spart Geld, macht aber den ersten Besuch nach einer ruhigen Phase langsamer. Für eine neue App ist das oft ein vernünftiger Tausch; wisse nur, dass es passiert.

Die Projektseite ist mit 5.000 Zeilen langsam. Füge serverseitige Paginierung (25 pro Seite) hinzu, lege Datenbankindizes für die Spalten an, nach denen wir filtern und sortieren, und zeige einen Ladezustand, während die nächste Seite lädt.

Schritt 7: Betriebliche Grundlagen

Ein paar kleine Dinge unterscheiden eine Hobby-App von einer, der Menschen vertrauen:

Eine eigene Domain mit HTTPS. Siehe wie du eine eigene Domain verbindest.
Transaktions-E-Mails von einer verifizierten Domain für Bestätigungen bei der Registrierung und Passwort-Zurücksetzen — behandelt in wie du E-Mails aus deiner App verschickst.
Datenschutzerklärung und Bedingungen, die beschreiben, was du tatsächlich erhebst. Kopiere keine Compliance-Aussagen, die du nicht erfüllst.
Ein Support-Weg — selbst eine überwachte E-Mail-Adresse.
Getrennte Test- und Live-Schlüssel für Zahlungen und E-Mail und ein klarer Vermerk, welche Umgebung welchen nutzt.

Schritt 8: Eine saubere Übergabe

Früher oder später arbeitet jemand anderes an der App: ein Freelancer, ein neuer Mitgründer oder du selbst in sechs Monaten. Mach es einfach:

Eine README, die erklärt, wie man sie lokal startet, welche Umgebungsvariablen sie braucht (nur Namen, niemals Werte) und wie man sie veröffentlicht.
Die Checkliste für die wichtigsten Abläufe und die automatisierten Tests.
Eine kurze Architekturnotiz: Frontend, Backend, Datenbank, Drittdienste und wo jeder davon gehostet wird.
Zugriffsliste: wer Admin-Zugriff auf Domain, Hosting, Datenbank, Zahlungs- und E-Mail-Konten hat. Lege diese Konten unter einer geschäftlichen E-Mail-Adresse an, nicht unter einer privaten.
Der Code in Git, am besten synchronisiert mit einem Repository, das dir gehört. Wenn du das Hosting später wechseln willst, lies wie du eine mit KI gebaute App exportierst und selbst hostest.

Die KI kann das meiste davon für dich entwerfen:

Schreibe eine README für dieses Projekt, für eine Entwicklerin, die es noch nie gesehen hat: was die App tut, der Tech-Stack, wie man sie lokal startet, jede Umgebungsvariable, die sie liest (nur Namen und Zweck), wie das Datenbankschema aufgebaut ist und wie man sie veröffentlicht.

Checkliste für die Produktionsreife

Wichtige Abläufe sind aufgeschrieben und getestet, einschließlich „kann nicht auf fremde Daten zugreifen“
Serverseitige Berechtigungs- und Eingabeprüfung auf jeder Datenroute
Keine geheimen Schlüssel im Frontend-Code; abgeflossene Schlüssel rotiert
Ratenbegrenzung bei Anmeldung und allem, was Geld kostet
Fehlerverfolgung und Verfügbarkeitsalarme, die in ein Postfach gehen, das du liest
Datenbank-Backups außerhalb des Hostings der App, mit einer erfolgreich getesteten Wiederherstellung
Paginierung und Indizes mit realistischen Daten geprüft
Eigene Domain, verifizierte Versanddomain, Datenschutzerklärung
README und Zugriffsliste für die nächste Person

So machst du es mit Mythex

Wenn du den Prototyp in Mythex gebaut hast, sind die meisten dieser Schritte Prompts im selben Projekt. Tippe /test, und Mythex klickt die Live-Vorschau wie ein Nutzer durch und meldet kaputte Abläufe — siehe App-Tests. Schlüssel gehören in die Projektgeheimnisse statt in den Chat. Jeder erfolgreiche Agent-Durchlauf speichert einen Checkpoint deiner Dateien, zu dem du zurückkehren kannst, und das Veröffentlichen gibt dir eine Live-URL mit Hosting; Hosting und Datenbank werden aus demselben Guthaben abgerechnet (Hosting-Limits erklärt, wie Apps und Datenbanken in den Ruhezustand gehen und wieder aufwachen). Checkpoints sichern Dateien, nicht Datenbankzeilen, also plane trotzdem deine Daten-Backups. Im Pro-Tarif kannst du eine eigene Domain verbinden und den Code exportieren oder mit deinem eigenen GitHub-Repository synchronisieren, um ihn zu übergeben.

Fragen

Was ist der Unterschied zwischen einem Prototyp und einer produktiven App?

Ein Prototyp beweist, dass eine Idee funktioniert, solange du ihn vorsichtig benutzt. Eine produktive App funktioniert weiter, wenn Fremde sie achtlos benutzen: Sie schützt deren Daten, übersteht fehlerhafte Eingaben, meldet dir, wenn sie ausfällt, und lässt sich wiederherstellen, wenn etwas schiefgeht.

Kann eine mit KI gebaute App produktiv eingesetzt werden?

Ja, wenn du sie so prüfst, wie du jede andere App prüfen würdest. Der Code, den eine KI schreibt, ist normaler Code. Was sie oft auslässt, wenn man nicht danach fragt, ist die unscheinbare Arbeit: Zugriffsprüfungen, Eingabevalidierung, Fehlerbehandlung, Logging und Backups.

Brauche ich automatisierte Tests vor dem Launch?

Du brauchst mindestens eine wiederholbare Prüfung deiner wichtigsten Abläufe vor jeder Veröffentlichung. Bei einer kleinen App kann das eine schriftliche Klick-Checkliste sein. Wenn die App wächst, bitte die KI, automatisierte Tests für die Abläufe zu schreiben, die dir Geld bringen oder kosten.

Wie sichere ich die Datenbank einer App?

Erstelle regelmäßig Exporte der Datenbank (bei Postgres z. B. ein pg_dump) und speichere sie außerhalb des Hostings der App. Teste außerdem mindestens einmal die Wiederherstellung, denn ein ungetestetes Backup ist nur eine Hoffnung.