Zum Inhalt springen
Alle Artikel

Vom KI-Prototyp zur Produktion: die acht Schichten, die ich ergänze, in dieser Reihenfolge

App-Builder wie Lovable, Bolt oder v0 liefern in wenigen Tagen ein funktionierendes Produkt. Dann kommen echte Kunden, Zahlungen und Personendaten, und der Prototyp fühlt sich plötzlich zerbrechlich an: Eine kleine Änderung legt den Checkout lahm, niemand weiss, ob die Backups funktionieren, und die KI, die alles gebaut hat, schreibt munter weiter um. Der übliche Rat lautet: neu schreiben. Ich habe zwei solche Prototypen ohne Neuschreiben in Produktion gebracht. Das sind die Schichten, die ich ergänze, in dieser Reihenfolge, und warum die Reihenfolge zählt.

Aktualisiert 11 Min. Lesezeit

1. An einem Nachmittag Bilanz ziehen

Den Code nach GitHub exportieren, falls er noch nicht dort liegt, und aufschreiben, was die App tatsächlich tut: Registrierung und Login, Zahlungen, E-Mails, Datei-Uploads, Admin-Ansichten, geplante Jobs, KI-Aufrufe. Alles markieren, was Geld oder Personendaten berührt. Diese Liste ist Ihre Risikokarte, und sie ist meist kürzer und klarer, als man befürchtet.

Dann prüfen, wo die Secrets liegen. In generierten Apps landen sie oft im Frontend-Code, in einer geteilten .env-Datei oder im Chatverlauf mit dem KI-Builder. Auch die Datenbank ansehen: Welche Tabellen gibt es, welche haben keine Zugriffsregeln, welche Spalten enthalten Personendaten? Der Readiness-Check unten macht aus diesem Nachmittag eine Punktzahl, damit Sie auf einen Blick sehen, wo es losgeht, und später Fortschritt zeigen können.

Tipp aus der Praxis

Das gebaute JavaScript-Bundle nach dem Service-Role-Key oder dem Zahlungs-Secret durchsuchen. Steht es dort, heute rotieren, vor allem anderen auf dieser Liste.

Interaktiv

Ist Ihre KI-gebaute App bereit für Produktion?

Haken Sie ab, was schon stimmt. Was übrig bleibt, ist Ihre To-do-Liste, in Reihenfolge.

0/12 bereit

Ihre nächsten drei Schritte

  1. Code liegt in Git, Änderungen laufen über Pull Requests
  2. Keine geheimen Keys im Frontend, Server-Keys nur auf dem Server
  3. Row-Level-Security (oder Gleichwertiges) auf jeder Tabelle
Production-Readiness-Review anfragen
Alle Rechner und Checklisten

2. Staging und Produktion trennen

Zwei Umgebungen mit eigener Datenbank, eigenen Keys und eigenen Drittanbieter-Konten im Testmodus. Jede Änderung geht zuerst über Staging, Datenbankmigrationen eingeschlossen, und nichts erreicht die Produktion, was dort nicht gelaufen ist. Mit Supabase liefert ein zweites Projekt oder Branching eine Staging-Datenbank; auf Vercel bekommt jeder Pull Request über Preview-Deployments eine eigene URL zum Durchklicken.

Dieser eine Schritt beseitigt die meisten 'auf der Live-Seite kaputt'-Momente, denn der KI-Builder und die Entwickler haben jetzt einen Ort, an dem sie gefahrlos falsch liegen dürfen. Staging nah an der Produktion halten: gleiche Konfiguration, gleiche Erweiterungen, realistische, aber anonymisierte Daten. Ein Staging, das auseinanderdriftet, wird zu einem Ort, an dem alles funktioniert und nichts etwas beweist. Die Produktions-Checkliste von Supabase ist dabei eine gute Begleiterin: Sie geht die Einstellungen durch, die ein Hobbyprojekt von einem Live-System unterscheiden, von Netzwerkbeschränkungen bis zum E-Mail-Anbieter.

Vom Prototyp zur Produktion: Jede Änderung geht über Git, CI und Staging; Backups beweisen sich jede Nacht; synthetische Checks beobachten, was Kunden tun.
Auslieferungsarchitektur vom KI-Prototyp zur Produktion: Ein KI-App-Builder pusht nach GitHub, die CI führt Tests und einen Migrations-Probelauf aus, Änderungen gehen auf Staging und dann in Produktion auf Vercel mit Supabase und Row-Level-Security, Secrets kommen über OIDC, Backups gehen in einen Object Store mit nächtlichem Restore-Test, und synthetische Checks überwachen die Live-Seite.

3. Festlegen, wer was lesen darf

Generierter Code vertraut oft dem Browser: Das Frontend versteckt einen Button und hält das für Sicherheit. In Produktion muss die Datenbank das durchsetzen, denn jeder kann Ihre API auch ohne Ihr Frontend aufrufen. Row-Level-Security auf jeder Tabelle einschalten, Policies pro Rolle schreiben und die kritischen Prüfungen in serverseitigen Funktionen wiederholen. Fehlerhafte Zugriffskontrolle steht seit Jahren ganz oben in den OWASP Top 10, und KI-gebaute Apps sind keine Ausnahme.

Dann pro Rolle einen Test schreiben, der Daten zu lesen und zu schreiben versucht, die ihn nichts angehen: die Rechnungen einer anderen Organisation, eine Admin-Einstellung, die Daten eines gelöschten Nutzers. Diese Tests sind billig geschrieben und unbezahlbar, wenn die KI eine Policy ändert, ohne Bescheid zu sagen. Auf einer Plattform hiess das Policies auf jeder Tabelle und eine Testsuite mit über tausend Dateien, und genau diese Suite lässt das Team weiter schnell ausliefern.

sql
-- Members only see invoices of their own organisation
alter table invoices enable row level security;

create policy "members read own org invoices"
  on invoices for select
  using (
    org_id in (
      select org_id from memberships
      where user_id = auth.uid()
    )
  );

Tipp aus der Praxis

Eine ungetestete Policy ist eine Vermutung. In der Testsuite als jede Rolle einloggen und versuchen, Daten einer anderen Organisation zu lesen; der Test besteht nur, wenn die Datenbank Nein sagt.

Advanced Row Level Security (RLS) Policies // Authorization Deep Dive, Supabase (YouTube). Wird erst nach Ihrem Klick von YouTube geladen.

4. Backups, die schon zurückgespielt wurden

Die Backups des Hosting-Anbieters sind ein Anfang, kein Plan. Wird das Konto gesperrt, fällt die Region aus oder löscht jemand das Projekt, verschwinden diese Backups mit. Zusätzlich verschlüsselte Dumps nach Zeitplan bei einem anderen Anbieter ablegen und jede Nacht einen davon in ein separates Projekt zurückspielen, mit einer Prüfung, ob die Zeilenzahlen stimmen. Hochgeladene Dateien brauchen dasselbe: auf einen zweiten Object Store spiegeln.

Die Zuverlässigkeitssäulen der Well-Architected Frameworks von Azure und AWS stellen beide dieselbe unbequeme Frage: Wann haben Sie zuletzt eine Wiederherstellung getestet? Auf den Produktionsplattformen, die ich betreibe, läuft der Restore-Test jede Nacht, und nur deshalb kann ich sagen, dass die Backups funktionieren. Ein nie zurückgespieltes Backup ist eine Hoffnung, kein Plan, und das will man nicht mitten in einem Vorfall herausfinden.

bash
# Nightly: dump, encrypt, ship to another provider, prove it restores
pg_dump "$PROD_DB_URL" --format=custom --file=prod.dump
age -r "$BACKUP_PUBKEY" -o prod.dump.age prod.dump
aws s3 cp prod.dump.age "s3://backups-offsite/$(date +%F)/" \
  --endpoint-url "$OFFSITE_S3_ENDPOINT"
pg_restore --clean --if-exists --no-owner -d "$RESTORE_TEST_DB_URL" prod.dump
psql "$RESTORE_TEST_DB_URL" -c "select count(*) from public.bookings;"

5. Eine Release-Pipeline, die Nein sagen kann

Nur Pull Requests, keine direkten Pushes auf main, auch nicht für die KI. Die CI prüft Typen, lintet mit einer Baseline, die nur besser werden darf, führt Unit-Tests aus und spielt Datenbankmigrationen probeweise gegen Staging durch, bevor etwas gemergt wird. Eine Migration, die um 15 Uhr auf Staging scheitert, ist eine Lektion; dieselbe Migration um 3 Uhr nachts in Produktion ist ein Vorfall.

Nach dem Merge nur ausliefern, was sich geändert hat, und einen Smoke-Test gegen die Live-Seite laufen lassen: Kann sich jemand registrieren, einloggen und bis zum Checkout kommen? Wenn nicht, automatisch oder per Klick zurückrollen. Kleine, umkehrbare Schritte summieren sich schneller als grosse, vorsichtige: Eine Plattform hat so in zehn Monaten 3'025 Pull Requests gemergt, und die Pipeline hat dieses Tempo sicher gemacht.

yaml
# .github/workflows/ci.yml (excerpt)
on: pull_request
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22 }
      - uses: supabase/setup-cli@v1
      - run: npm ci
      - run: npm run typecheck && npm run lint && npm test
      - name: Migration dry run against staging
        run: supabase db push --dry-run --db-url "$STAGING_DB_URL"
        env:
          STAGING_DB_URL: ${{ secrets.STAGING_DB_URL }}

6. Überwachen, was Kunden wirklich tun

CPU-Grafiken verraten nicht, dass seit Mittag niemand buchen konnte. Das Google-SRE-Buch sagt es schlicht: Symptome überwachen, die Nutzer spüren, nicht nur Ursachen. Outside-in-Checks auf die Abläufe legen, die zählen, Registrierung, Checkout und Buchung, alle paar Minuten von ausserhalb des Hostings, damit Sie von einem kaputten Ablauf hören, bevor ein Kunde schreibt.

Dann Geschäftszustände beobachten, nicht nur technische. 'Zahlung erfolgreich, aber keine Buchung angelegt' und 'seit sechs Stunden an einem Werktag keine Buchung' sind die Alerts, die die teuren Fehler fangen. Auf einer Plattform hiess das stündliche Probes auf die Buchungsstrecke, eine tägliche synthetische Zahlung und ein Alarm bei Buchungsflaute. Nur bei Zustandswechseln alarmieren, ausgelöst und behoben, damit die Leute die Alerts weiter lesen, statt den Kanal stummzuschalten.

Tipp aus der Praxis

Jeden Tag eine synthetische Zahlung im Testmodus durch den echten Checkout schicken. Sie fängt kaputte Webhooks lange bevor es ein Kunde tut.

7. Secrets und Zugriff ohne langlebige Keys

Secrets aus dem Code, aus Chatverläufen und von den Laptops der Leute holen. Jede Umgebung bekommt eigene Secrets im Secret Store der Plattform. Die CI meldet sich per OpenID Connect statt mit gespeicherten Keys bei der Cloud an, damit in GitHub kein langlebiger Zugang liegt, der leaken könnte. Service-Role-Keys bleiben auf dem Server und erreichen nie den Browser.

Zugriff für Menschen folgt derselben Idee. Jeder bekommt ein eigenes Konto mit den minimal nötigen Rechten, Admins nutzen Multi-Faktor-Authentifizierung, und Zugriffe werden am Tag des Austritts entfernt. Das in einer einseitigen Zugriffsmatrix festhalten: Wer darf deployen, wer darf Produktionsdaten lesen, wer darf die Abrechnung ändern? Das dauert eine Stunde und beantwortet die ersten Fragen jedes Security-Fragebogens, den Kunden Ihnen je schicken. Jedes Quartal überprüfen; Zugriffe, auf die niemand schaut, wachsen nur.

8. Leitplanken für die KI, die weiterbaut

Der Coding-Agent, der den Prototyp gebaut hat, wird ihn weiter ändern, also bekommt er Regeln, so wie man einen neuen Entwickler einarbeitet. Eine schriftliche Anweisungsdatei im Repository sagt, was er anfassen darf und was nicht, welche Befehle er vor einem Pull Request ausführen muss und welche Bereiche immer einen Menschen brauchen: Login, Zahlungen, Löschen von Daten, Zugriffs-Policies.

Seine Pull Requests klein halten und ihn seine Arbeit belegen lassen. Ein Check der wichtigsten Abläufe in einem echten Browser vor jedem Release, ein Screenshot oder Testergebnis in jedem Pull Request, der einen Nutzerablauf ändert, und eine menschliche Freigabe für die sensiblen Bereiche. Der Agent behält sein Tempo; Pipeline, Tests und Review halten die Produktion sicher. Genau darum geht es: das Tempo eines KI-gebauten Produkts mit der Zuverlässigkeit, die Kunden von einem echten erwarten.

Tipp aus der Praxis

Den Agenten beweisen lassen: Kein Pull Request, der einen Nutzerablauf berührt, wird ohne Browser-Testergebnis oder Screenshot gemergt.

Fazit

Das Tempo des Prototyps behalten und die Sicherheit der Produktion schichtweise ergänzen. Sie brauchen kein Neuschreiben, sondern diese acht Schritte, in dieser Reihenfolge.

Weitere Artikel

    Kontakt aufnehmen

    Erzählen Sie mir von Ihrem Projekt, ich antworte innerhalb von 1–2 Werktagen.

    Dominik Heinrich
    Unternehmen
    MADO Consulting

    Weltweit verfügbar, remote. Vor Ort auf Anfrage, je nach Land.

    Ich antworte innerhalb von 1–2 Werktagen. Freie Termine: siehe Kalender

    Öffnet hier den Buchungskalender von Calendly. Beim Laden werden Daten an Calendly übertragen (siehe Impressum).