# SaaS mit KI bauen: vom MVP zum ersten Kunden

URL: https://agentvera.dev/de/blog/build-saas-mvp-with-ai/ · Veröffentlicht: 2026-10-11

Praxisleitfaden: SaaS mit KI bauen. MVP eingrenzen, Spec für den Agenten schreiben, Next.js, Supabase und Stripe, Mandantentrennung, Tests, Deploy, Monitoring.

**Kurz gesagt:**

- Schneide das MVP auf einen Kernablauf zu und halte Entscheidungen, Regeln und Ausgeschlossenes in CLAUDE.md oder AGENTS.md fest, die die Agenten zu Beginn jeder Session lesen.
- Gib jeder Tabelle eine organization_id, setze die Mandantentrennung per Row-Level-Security in der Datenbank durch und teste sie mit zwei Nutzern in getrennten Organisationen.
- Der Abo-Status darf sich nur über signaturgeprüfte Stripe-Webhooks ändern, nie über die Erfolgsseite. Vor echtem Geld und echten Daten sollte ein erfahrener Entwickler draufschauen.

Heute kannst du ein SaaS mit KI bauen: Ein [Coding-Agent](/de/glossary/coding-agent/) wie Claude Code oder Codex schreibt Registrierung, Abos, Dashboard und API in wenigen Tagen. Ein funktionierendes MVP braucht aber mehr als „bau mir ein SaaS“: einen auf einen Kernablauf zugeschnittenen Umfang, eine schriftliche Spec, die der Agent in jeder Session liest, und Tests auf den Pfaden, in denen Geld und Datentrennung stecken. Dieser Beitrag zeigt meinen Ablauf vom Scope bis zum Deploy.

Ziel ist ein Leitfaden, dem auch jemand folgen kann, der wenig oder gar nicht programmiert. Einen Prototyp per [Vibe Coding](/de/glossary/vibe-coding/) rauszubringen ist leicht; ein Produkt am Leben zu halten, sobald jemand eine Kreditkarte eingibt, ist der schwere Teil. Deshalb markiere ich, wo du schnell sein kannst und wo du bremsen musst.

## 1. Den Umfang auf einen Kernablauf zuschneiden

MVPs scheitern selten am Code. Sie scheitern am Umfang. Der Agent schreibt alles, was du verlangst; das Problem ist, dass jedes zusätzliche Feature getestet, gewartet und debuggt werden muss.

Schreibe vor dem Start einen Satz auf: „Der Nutzer macht ___ und bekommt dafür ___.“ Zum Beispiel: „Eine Agentur lädt Social-Media-Posts eines Kunden hoch, und der Kunde gibt sie über einen einzigen Link frei.“ Alles außerhalb dieses Satzes kommt in Version zwei.

Eine erste Version braucht meist nur:

- Registrierung, Login, Passwort zurücksetzen
- Eine Organisation (Mandant) mit eingeladenen Mitgliedern
- Einen Kernablauf (der Satz oben)
- Einen bezahlten Tarif, monatliches Abo
- Eine einfache Einstellungsseite und einen Link zum Billing-Portal

Benachrichtigungscenter, Rollenmatrix, mehrere Sprachen, Mobile-App, Admin-Panel: später. Wenn Kunden für den Kernablauf zahlen, sagen sie dir, was sie sonst noch brauchen.

## 2. Eine Spec schreiben, der der Agent folgt

Agenten behalten zwischen Gesprächen nichts im Gedächtnis. Claude Code liest `CLAUDE.md` im Projektstamm in jeder Session; Codex und viele andere Agenten lesen `AGENTS.md`. Schreib deine Entscheidungen dort hinein, dann startet jede neue Session mit denselben Regeln. Wenn du beide Agenten nutzt, halte den Inhalt in einer Datei und verweise aus der anderen darauf.

Eine brauchbare Spec ist kurz und konkret:

```markdown
# Project: ApproveLink (MVP)

## Product
Agencies upload posts; the client approves or comments from one link.

## Stack
- Next.js (App Router, TypeScript), Tailwind
- Supabase: Postgres, Auth, Storage
- Stripe: one plan, monthly subscription, Checkout + Customer Portal
- Tests: Vitest (unit), Playwright (end to end)

## Rules
- Every table has organization_id; RLS is on for every table.
- Subscription status changes only from the Stripe webhook.
- Database changes only through migration files.
- Secrets live in .env.local; never in code or logs.
- Ask before adding a new package.
- After every task: pnpm lint && pnpm test

## Out of scope (for now)
Roles, i18n, mobile, admin panel.
```

Der Abschnitt „Out of scope“ ist wichtig. Agenten wollen hilfreich sein und ergänzen Dinge, um die du nicht gebeten hast; eine schriftliche Grenze reduziert das spürbar.

## 3. Den Stack wählen: langweilig ist gut

Beim Arbeiten mit KI ist der beste Stack der, zu dem der Agent die meisten Beispiele gesehen hat. Für ein MVP dieser Art würde ich nehmen:

- **Next.js + TypeScript:** Frontend und API in einem Projekt. TypeScript fängt einen Teil der Agentenfehler schon beim Build ab.
- **PostgreSQL (Supabase oder ein anderes verwaltetes Postgres):** Relationale Daten, Row-Level-Security (RLS) und Migrationen. Supabase liefert zusätzlich Auth und Dateispeicher an einem Ort.
- **Fertige Auth:** Supabase Auth, Auth.js oder Clerk. Lass den Agenten Passwortspeicherung und Session-Handling nicht von Grund auf schreiben.
- **Stripe-Abos:** Checkout für die Zahlungsseite, Customer Portal für Tarifwechsel und Kündigung. Ein Kartenformular baust du nie selbst.
- **Vercel oder eine ähnliche Plattform:** Deployt bei jedem Push und gibt jedem Branch eine Preview-URL.

Zu installieren sind: Node.js (LTS), pnpm, Git, ein GitHub-Konto, die Supabase CLI, die Stripe CLI und ein Coding-Agent (`claude` oder `codex`).

```bash
pnpm create next-app@latest approvelink --typescript --tailwind --app
cd approvelink
git init && git add -A && git commit -m "chore: empty project"
```

Leg die Spec in den Stamm dieses Ordners und committe sie ebenfalls.

## 4. Der erste Prompt: erst planen, dann coden

Meine erste Nachricht verlangt keinen Code, sondern einen Plan. Einen Plan zu lesen und zu korrigieren ist viel billiger, als 40 falsch geschriebene Dateien zurückzusetzen.

```text
Read CLAUDE.md. Don't write code yet.
Produce an implementation plan for this MVP:
1. Database tables (fields, relations, RLS policies)
2. Pages and API routes
3. The Stripe flow (which webhook events, where subscription status lives)
4. 6–8 small steps in order, each with what gets tested at the end
List anything unclear as questions at the end.
```

Lies den Plan, beantworte die Fragen, passe bei Bedarf die Spec an. Lass dann die Schritte einzeln umsetzen:

```text
Implement step 1 of the plan: write the migration for the organizations,
memberships and projects tables and add the RLS policies. When done,
apply the migration to the local database, write a test proving two
different users can't see each other's data, and run it. Then stop.
```

„Then stop“ ist Absicht. Nach jedem Schritt sehe ich mir den Diff an und committe, sodass es einen sauberen Punkt zum Zurückgehen gibt, wenn der Agent abdriftet.

## 5. Mandantentrennung: der gefährlichste Teil

Der schlimmste SaaS-Bug lautet: „Kunde A hat die Daten von Kunde B gesehen.“ Der Code des Agenten sieht meist gut aus, weil du beim Bauen mit einem Nutzer testest. Das Problem zeigt sich, wenn der zweite Kunde kommt.

Meine Regeln:

- **`organization_id` in jeder Tabelle.** Keine Ausnahmen, auch nicht bei Kindtabellen.
- **Die Datenbank erzwingt den Filter.** Aktiviere bei Supabase/Postgres RLS für jede Tabelle und schreibe die Policy anhand der Organisationen, zu denen der Nutzer gehört. Ein `where organization_id = ...` im App-Code allein reicht nicht; der Agent kann es in der nächsten Abfrage vergessen.
- **Der Service-Role-Key bleibt auf dem Server.** Er umgeht RLS. Er darf nie in Code landen, der an den Browser ausgeliefert wird; in Next.js gehört er nie in eine `NEXT_PUBLIC_`-Variable.
- **Mit zwei Nutzern testen.** Lege zwei Organisationen an und versuche, angemeldet als der eine, den Datensatz des anderen per ID abzurufen. Dieser Test sollte automatisiert sein und bei jeder Änderung laufen.

Frag den Agenten direkt: „List every place in this project that bypasses RLS.“ Die Antwort sollte Servercode mit Service Role und die Webhooks nennen; wenn es mehr ist, frag nach dem Grund.

## 6. Migrationen: die Datenbank nie von Hand ändern

Will der Agent eine Spalte hinzufügen, soll er das mit einer Migrationsdatei tun, nicht per Klick im Dashboard. Mit der Supabase CLI:

```bash
supabase start                      # local Postgres (needs Docker)
supabase migration new add_projects # empty migration file
supabase db reset                   # apply all migrations from scratch
supabase db push                    # apply to the remote database
```

Führe `db reset` regelmäßig aus: Wenn sich Migrationen nicht sauber von null anwenden lassen, gibt es auch in Produktion Probleme. Sobald du live bist, lies jede Migration, die der Agent schreibt. Siehst du `DROP COLUMN`, `DROP TABLE`, ein `UPDATE` ohne `WHERE` oder einen sperrenden Index auf einer großen Tabelle, halte an und frag nach dem Warum. Eine Migration, die Daten löscht, lässt sich nicht rückgängig machen.

## 7. Die Geldpfade testen

Du brauchst nicht für alles Tests; die MVP-Zeit ist knapp. Aber diese Pfade sollten nicht ungetestet in Produktion gehen:

1. **Registrierung → Organisation anlegen → Kernablauf.** Ende-zu-Ende mit Playwright.
2. **Stripe-Webhooks.** Aktualisiert sich der Abo-Status korrekt bei `checkout.session.completed`, `customer.subscription.updated`, `customer.subscription.deleted` und `invoice.payment_failed`?
3. **Zugriff ohne Zahlung.** Wird die bezahlte Funktion bei gekündigtem Abo oder fehlgeschlagener Zahlung wirklich gesperrt?
4. **Datentrennung.** Der Zwei-Nutzer-Test von oben.

Stripe-Webhooks probierst du lokal so aus:

```bash
stripe login
stripe listen --forward-to localhost:3000/api/webhooks/stripe
stripe trigger checkout.session.completed
```

Ein Prompt für den Agenten:

```text
Review the Stripe webhook route. Is the signature verified? What happens
if the same event arrives twice (idempotency)? Which table holds
subscription status? Write tests for these four events:
checkout.session.completed, customer.subscription.updated,
customer.subscription.deleted, invoice.payment_failed.
Run them and show me the result.
```

Ein häufiger Fehler: Der Agent aktiviert das Abo auf der „Success“-Seite, auf die Stripe weiterleitet. Diese URL kann jeder von Hand öffnen. Der Status darf sich nur über einen signaturgeprüften Webhook ändern.

## 8. Deploy und Monitoring

Auf einer Plattform wie Vercel ist der Ablauf einfach: Repo auf GitHub pushen, Projekt verbinden, Umgebungsvariablen im Dashboard eintragen. Jeder Pull Request bekommt eine eigene Preview-URL; probiere Änderungen dort aus, bevor sie in Produktion gehen.

Meine Checkliste vor dem Livegang:

- Umgebungsvariablen in Produktion gesetzt; Stripe-Live- und Test-Keys nicht vertauscht
- Ein Live-Webhook-Endpunkt in Stripe konfiguriert, sein Signing Secret in einer Umgebungsvariable
- Migrationen auf die Produktionsdatenbank angewendet
- Supabase-Auth-Redirect-URLs für die Produktionsdomain gesetzt
- Datenbank-Backups aktiv

Für das Monitoring fügst du einen Error-Tracking-Dienst wie Sentry hinzu, damit du Fehler siehst, bevor ein Nutzer schreibt „es ist kaputt“. Dem Agenten genügt diese Anweisung: „Add Sentry to the Next.js project, capture server and client errors, and don’t attach user emails or secret values to events.“ Ergänze außerdem einen einfachen Uptime-Check.

## Wo die KI danebenliegt

- **APIs erfinden, die es nicht gibt.** Besonders bei neuen Bibliotheksversionen. Wenn Build oder Tests brechen, gib den Fehler unverändert an den Agenten und bitte ihn, die offizielle Doku zu prüfen.
- **Den Test ändern, damit er besteht.** Taucht eine Testdatei im Diff auf, frag nach dem Grund.
- **Pakete hinzufügen, die du nicht brauchst.** Die Regel „vor neuen Paketen fragen“ in der Spec zahlt sich hier aus.
- **Fehler verschlucken.** Leere `catch {}`-Blöcke machen Zahlungsfehler unsichtbar.
- **Autorisierung im Client.** Einen Button zu verstecken ist keine Sicherheit; die Prüfung gehört auf den Server und in die Datenbank.
- **Den Umfang ausweiten.** Features, die mit „Ich habe auch noch … hinzugefügt“ ankommen, machst du rückgängig oder verschiebst sie in einen eigenen Branch.
- **Kontext in langen Sessions verlieren.** Je länger ein Gespräch wird, desto mehr vergisst der Agent frühe Entscheidungen. Starte pro Schritt eine frische Session; dauerhafte Entscheidungen stehen ohnehin in der Spec. Eine Session zu schließen, bevor das [Kontextfenster](/de/glossary/context-window/) voll ist, schützt Qualität und [Token](/de/glossary/token/)-Kosten.

## Sicherheit: kurz, aber ernst

- **Secrets gehören in `.env.local`.** Prüfe, dass die Datei in `.gitignore` steht. Wenn ein Key je committet wurde, widerrufe ihn und stelle einen neuen aus; ihn aus der Historie zu löschen reicht nicht.
- **Füge nie API-Keys in den Chat ein.** Der Agent muss den Key nicht sehen, nur den Variablennamen.
- **Lies die Befehle, die der Agent ausführt.** Besonders `rm`, `git push --force`, Datenbankbefehle und `curl … | sh`. Genehmige automatisch nur sichere Aktionen wie Dateien lesen und Tests ausführen.
- **Richte den Agenten nicht auf die Produktionsdatenbank.** Lass ihn mit einer lokalen oder Testdatenbank arbeiten.
- **Validiere Eingaben auf dem Server.** Lass jede API-Eingabe mit einer Schema-Bibliothek wie Zod prüfen.
- **Prüfe Abhängigkeiten.** Gib die Ausgabe von `pnpm audit` ab und zu an den Agenten.

## Wann ein menschlicher Entwickler dazukommt

Wenn eines davon zutrifft, lohnen sich ein paar Stunden Review durch einen erfahrenen Entwickler:

- Vor der ersten echten Zahlung (Webhooks, Abo-Status, Rückerstattungen)
- Wenn die Kundendaten personenbezogene Daten enthalten (DSGVO und ähnliche Pflichten)
- Wenn ein Enterprise-Kunde einen Sicherheitsfragebogen schickt
- Wenn du und der Agent denselben Bug drei Sessions in Folge nicht behoben habt
- Wenn Performance-Probleme beginnen (langsame Abfragen, fehlende Indizes)

Halte Spec, Migrationsordner und Testausgabe bereit, damit das Review schnell geht. Ein mit Agent geschriebenes Projekt, das in kleinen Schritten committet und von Tests abgedeckt ist, kann ein Entwickler schnell nachvollziehen.

## So mache ich das mit AgentVera

All das funktioniert in einem einzigen Terminal. Ich nutze AgentVera, um mehrere Agenten gleichzeitig zu steuern; diese Teile helfen dabei:

- **Frontend und Backend in getrennten Worktrees.** Im [Workspace](/de/features/workspace/) öffne ich einen Claude-Code-Agenten für API und Webhooks und einen Codex-Agenten für die UI, jeweils in einem eigenen [Git-Worktree](/de/glossary/git-worktree/). Sie fassen nicht dieselben Dateien an und stören sich so nicht. Die Methode steht in [Git-Worktrees für parallele Agenten](/de/blog/git-worktree-parallel-agents/).
- **Der Diff vor dem Merge.** Das [Git-Panel](/de/features/git-and-github/) zeigt die Änderungen jedes Worktrees, und das [Code-Review](/de/features/code-review/) prüft jeden abgeschlossenen Turn. Worauf du achten solltest, steht in [KI-Code-Review](/de/blog/ai-code-review/).
- **Die Datenbank sehen.** Mit dem [Datenbank-Manager](/de/features/database-manager/) öffne ich die Tabellen im lokalen Postgres und prüfe, was der Agent tatsächlich geschrieben hat; [DB Guard](/de/features/db-guard/) markiert riskante Migrationen am Ende eines Turns.
- **Previews.** [Preview-Umgebungen](/de/features/preview-environments/) geben dem Dev-Server jedes Worktrees eine eigene Adresse, sodass ich zwei Branches nebeneinander ausprobieren kann.
- **Tokens im Blick.** Jedes Pane zeigt die aktuelle Kontextgröße; wenn sie anschwillt, schließe ich die Session und starte neu.

Das beschleunigt vieles, ersetzt aber nicht die Regeln oben: Spec, Tests und dein eigenes Review bleiben wichtig.

## Fazit

Ein SaaS mit KI zu bauen heißt weniger, Code zu generieren, und mehr, Entscheidungen aufzuschreiben und die kritischen Pfade zu schützen. Schneide den Umfang auf einen Ablauf zu, halte Entscheidungen in `CLAUDE.md` oder `AGENTS.md` fest, wähle einen langweiligen Mainstream-Stack, erzwinge die Mandantentrennung in der Datenbank, teste die Geldpfade und richte Monitoring ein, bevor du deployst. Lass einen Menschen draufschauen, bevor echtes Geld und echte Daten ins System kommen. Wenn du Agenten parallel laufen lassen willst, [lade AgentVera kostenlos herunter](/de/download/) und öffne deine ersten zwei Worktrees.

## Häufige Fragen

**Kann ich allein mit KI ein SaaS bauen?** Ein MVP mit einem Kernablauf kannst du mit Coding-Agenten allein ausliefern. Schwierig ist nicht das Generieren von Code, sondern den Umfang klein zu halten, dem Agenten eine schriftliche Spec zu geben und kritische Pfade wie Zahlungen und Zugriffskontrolle selbst zu testen und zu prüfen.

**Welchen Tech-Stack sollte ich nehmen, um ein SaaS mit KI zu bauen?** Nimm einen verbreiteten Stack, den die Agenten oft gesehen haben: Next.js, PostgreSQL (zum Beispiel Supabase), eine fertige Auth-Lösung und Stripe für Abos. Auf einem Mainstream-Stack erfindet der Agent weniger, und wenn du feststeckst, findest du schneller Hilfe.

**Was ist der häufigste Mandantenfehler in einem KI-gebauten SaaS?** Eine Abfrage, die den Mandantenfilter vergisst, sodass ein Kunde die Daten eines anderen sieht. Setze eine Mandanten-ID in jede Tabelle, erzwinge den Filter per Row-Level-Security in der Datenbank und teste mit zwei getrennten Nutzern.

**Wann sollte ein menschlicher Entwickler mein KI-gebautes SaaS prüfen?** Bevor echtes Geld und echte Kundendaten ins System kommen. Ein paar Stunden Review durch einen erfahrenen Entwickler bei Zahlungs-Webhooks, Autorisierung, Datentrennung und Migrationen kosten weit weniger als ein späteres Datenleck.

**Wie bringe ich die KI dazu, Stripe-Abos richtig einzurichten?** Sag dem Agenten, dass sich der Abo-Status nur über signaturgeprüfte Stripe-Webhooks ändern darf, nie über die Browser-Weiterleitung nach dem Checkout. Löse dann jedes Webhook-Event lokal mit der Stripe CLI aus und teste es.

---

**Über AgentVera.** AgentVera ist eine Desktop-App für macOS, Windows und Linux, entwickelt von Solviera Teknoloji. Sie führt 18 KI-Coding-Agenten (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) nebeneinander aus, pro Projekt, in echten Terminals mit den eigenen CLI-Installationen und Logins des Nutzers. Der kostenlose Plan hat unbegrenzt viele Agenten. Download: https://agentvera.dev/de/download/ · Preise: https://agentvera.dev/de/pricing/