SaaS mit Claude Code entwickeln: Mein Workflow für sichere Apps

Vibe-Coding-Tools wie Lovable, Bolt oder Base44 liefern schnell vorzeigbare Ergebnisse. Die Apps bleiben aber oft auf Prototyp-Niveau: Daten liegen offen, und die Plattform bricht zusammen, sobald die ersten echten Nutzer:innen kommen. Das liegt zum einen an fehlender Erfahrung, zum anderen daran, dass produktionsreife Software einen professionellen Entwicklungsprozess braucht.

In diesem Artikel zeige ich dir meinen kompletten Workflow mit Claude Code. Als Beispiel entwickeln wir ein Feature-Voting-Board als SaaS: Nutzer:innen registrieren sich, reichen Ideen für ein Produkt ein und stimmen darüber ab. Wenn du ganz neu bei Claude Code bist, lies vorher meine Einsteiger-Anleitung, wie du mit Claude Code deine erste Web-App entwickelst. Hier geht es um den Schritt danach: einen strukturierten Prozess, der auch bei größeren Projekten trägt.

Das Prinzip: ein Entwicklungsteam aus sechs KI-Rollen

Wenn du in Lovable oder ganz normal mit Claude Code arbeitest, übernimmt ein einziger Agent alle Aufgaben. Er schreibt Anforderungen, plant die Architektur, baut Frontend und Backend, testet und deployt. Dabei muss er ständig zwischen Kontexten wechseln und ist schnell mit Informationen überladen. Die Fehlerwahrscheinlichkeit steigt.

Ich trenne diese Aufgaben deshalb klar und simuliere ein professionelles Entwicklungsteam mit sechs spezialisierten Rollen. Jede Rolle hat eine eigene Anweisungsdatei mit den Best Practices ihres Fachgebiets:

Für jede Rolle starte ich im besten Fall eine neue Claude-Code-Session. So bleibt der Kontext schlank. Damit trotzdem nichts verloren geht, arbeiten alle Rollen mit denselben Dateien als gemeinsamer Wissensbasis. Dazu gleich mehr.

Der Tech-Stack

Für das Beispiel nutze ich diese Werkzeuge:

• VS Code mit der Claude-Code-Erweiterung. Visual Studio Code ist ein kostenloser Code-Editor von Microsoft und der weltweit meistgenutzte. Mit der Erweiterung hast du Dateien, Code, den Claude-Chat und sogar einen integrierten Browser an einem Ort.
• Claude Code mit mindestens einem Claude-Pro-Abo. Je nachdem, wie intensiv du arbeitest, erreichst du mit Pro nach etwa zwei Stunden dein Limit und musst ein paar Stunden warten. Mit Claude Max arbeitest du deutlich entspannter.
• Supabase als Backend-as-a-Service. Supabase bringt eine PostgreSQL-Datenbank für deine Daten mit, kümmert sich um Registrierung und Login und bietet außerdem Edge Functions (für die Anbindung von Drittsystemen und KI-Diensten), File Storage, Realtime-Funktionen und Vektordatenbanken.
• shadcn/ui als Bibliothek für fertige UI-Komponenten. Das beschleunigt die Entwicklung und sorgt dafür, dass die App von Anfang an hochwertig aussieht.
• GitHub als Cloud-Speicher und zur Versionierung deines Codes. Du kannst jederzeit auf alte Versionen zurück, und mehrere Personen können über Branches parallel an einer App arbeiten.
• Vercel als Hosting-Dienst, der deine App im Internet bereitstellt. Vercel lässt sich direkt mit GitHub verbinden.

Zusätzlich brauchst du lokal Node.js, damit du deine App über einen Entwicklungsserver unter localhost im Browser starten kannst, und Git, die lokale Versionsverwaltung, über die du später mit GitHub kommunizierst. Beides musst du nicht selbst installieren. Sag Claude Code einfach:

Bitte installiere die neueste Version von Node.js und Git auf meinem Rechner.

Schritt 1: Projekt-Template einrichten

Statt bei null anzufangen, starte ich jedes Projekt mit einem vorkonfigurierten Template. Darin liegen schon die Anweisungsdateien für alle sechs Rollen, die Kontextdateien und eine leere Next.js-App mit shadcn/ui. Next.js ist ein verbreitetes Framework für Web-Apps.

Das Template klonst du über das Terminal in VS Code (unter macOS im Menü Terminal → New Terminal) und vergibst dabei einen Projektnamen, bei mir voting-app. Danach wechselst du mit cd in den neuen Ordner und installierst mit npm install die Codepakete, die das Template benötigt. Das dauert nur ein paar Sekunden.

Anschließend startest du Claude über das Claude-Symbol oben rechts in VS Code und bittest ihn:

Bitte starte den Dev-Server.

Claude fragt dich zwischendurch, ob er bestimmte Befehle ausführen darf, etwa einen Terminal-Befehl im Hintergrund. Gib sie frei. Danach öffnest du localhost im Browser und siehst eine leere Next.js-App. Das ist dein Ausgangspunkt.

Ein Tipp aus meiner eigenen Debugging-Session: Öffne in VS Code genau den Projektordner, nicht den übergeordneten Ordner. Sonst findet Claude Code die Konfigurationsdateien im Projekt nicht.

Schritt 2: Supabase-Projekt anlegen und per MCP verbinden

Lege in deinem Supabase-Dashboard über New Project ein neues Projekt an. Generiere ein Datenbank-Passwort und speichere es sicher ab. Als Region wähle ich einen Standort in Europa.

Jetzt kommt der Teil, der den Entwicklungsprozess massiv beschleunigt: der Supabase MCP Server. MCP steht für Model Context Protocol. Das ist ein Standard, über den KI-Assistenten auf externe Systeme zugreifen können. Supabase bündelt seine Schnittstellen, etwa zum Anlegen von Tabellen oder Abfragen von Daten, auf einem MCP Server. Ist der angebunden, kann Claude Code dein komplettes Backend selbst konfigurieren.

Der aktuell einfachste Weg ist der gehostete MCP Server von Supabase. Du fügst ihn projektbezogen hinzu und meldest dich beim ersten Start im Browser bei Supabase an:

claude mcp add --scope project --transport http supabase "https://mcp.supabase.com/mcp?project_ref=DEINE_PROJECT_REF"

Damit entsteht im Projekt eine Datei .mcp.json. Mit dem Parameter project_ref beschränkst du den Zugriff auf genau dieses eine Projekt. Ob die Verbindung steht, prüfst du in Claude Code mit /mcp.

Falls du mit einem Access Token arbeitest

Alternativ kannst du den Server mit einem persönlichen Access Token aus deinem Supabase-Konto verbinden. Mit diesem Token lässt sich dein Supabase-Konto von außen steuern. Behandle ihn entsprechend:

• Vergib einen sprechenden Namen, zum Beispiel „VS Code“, damit du später weißt, wofür er ist.
• Setz ein Ablaufdatum. Du brauchst den Token nur während der Entwicklung. Ich nehme 30 Tage.
• Gib den Token nie als Prompt an Claude. Trag ihn selbst in die Datei ein und speichere sie.
• Schließ die Datei von GitHub aus, indem du sie in die .gitignore aufnimmst. Darin steht alles, was nicht veröffentlicht werden soll.

Bitte füge die .mcp.json zur .gitignore hinzu, damit sie nicht veröffentlicht wird.

Supabase selbst empfiehlt außerdem, den MCP Server nur mit einem Entwicklungsprojekt zu verbinden, nicht mit deiner Produktionsdatenbank mit echten Kundendaten. Mehr dazu, wie du Zugangsdaten generell vor Claude schützt, liest du in meinem Artikel Claude Code und deine .env-Datei.

Schritt 3: GitHub-Repository verbinden

Leg auf GitHub über New Repository ein neues Repository an, zum Beispiel voting-app. Wichtig: Stell die Sichtbarkeit auf Private, damit dein Code nicht öffentlich einsehbar ist. README, .gitignore und Lizenz brauchst du nicht, die bringt das Template mit.

Kopiere die URL des Repositorys und sag Claude Code:

Bitte verknüpfe diese App mit folgendem Repository: https://github.com/DEIN-NAME/voting-app

Ab jetzt kannst du Claude jederzeit bitten, deine Änderungen zu GitHub zu pushen oder den aktuellen Stand zu holen.

Die Projektstruktur: Kontext und Feature-Dateien

Zwei Bausteine machen den Workflow verlässlich.

Die Project-Context-Datei enthält den gesamten Projektkontext. Technisch: Tech-Stack, Projektstruktur, Agenten-Struktur und eine Liste der Features. Inhaltlich: Zweck und Ziel der App. Sie wird im Laufe der Entwicklung immer wieder ergänzt.

Die Feature-Dateien im Ordner features sind das Herzstück. Für jedes Feature gibt es eine eigene Markdown-Datei, die von Phase zu Phase wächst:

# PROJ-1: Benutzer-Authentifizierung

Status: Geplant

## User Stories
Als neuer Besucher möchte ich mich mit E-Mail und Passwort registrieren,
um Ideen einzureichen und abstimmen zu können.

## Akzeptanzkriterien
- [ ] User kann E-Mail und Passwort eingeben
- [ ] Bei falscher Kombination erscheint eine Fehlermeldung

## Edge Cases
- Doppelte E-Mail: Fehlermeldung "Diese E-Mail ist bereits registriert"
- Schwaches Passwort, ungültige E-Mail-Adresse

## Tech Design        (ergänzt der Solution Architect)
## QA-Testergebnisse  (ergänzt der QA Engineer)
## Deployment-Status  (ergänzt der DevOps Engineer)

Die Akzeptanzkriterien legen fest, wann ein Feature wirklich fertig ist. Edge Cases sind Sonderfälle, die abgefangen werden müssen. Alle Rollen nutzen die Feature-Datei als Single Source of Truth: Sie lesen daraus, was zu tun ist, und schreiben ihre Ergebnisse hinein.

Schritt 4: Anforderungen mit dem Requirements Engineer

Ich starte eine neue Session und rufe den Requirements Engineer auf, indem ich seine Anweisungsdatei mit @ im Chat referenziere. Dann beschreibe ich, was ich vorhabe:

Ich betreibe eine Aktienportfolio-Tracker-App und möchte von dir eine zusätzliche App als MVP. Und zwar ein Feature-Voting-Board, bei dem Nutzer Produktideen einreichen und abvoten können. Die Benutzer-Authentifizierung soll losgelöst von meiner ursprünglichen App sein. Ich möchte also ein neues Supabase-Backend mit dieser Anwendung verknüpfen und alle Daten dort speichern. Hilf mir bitte bei der Planung dieser App und der einzelnen Features.

Der Requirements Engineer stellt mir daraufhin Rückfragen, die ich per Single oder Multiple Choice beantworte. Bei mir waren das unter anderem:

• Wer nutzt das Board? Öffentliche Community, jeder kann mitmachen.
• Wie melden sich User an? Mit E-Mail und Passwort.
• Wie funktioniert das Voting? Nur Upvotes, einfach und positiv.
• Braucht es einen Admin-Bereich? Ja, vollständig: moderieren, löschen, Status ändern.
• Wer darf Ideen einreichen? Nur eingeloggte User.
• Kategorien? Nein.
• Kommentare? Ja, Diskussionen sollen möglich sein.
• Status-Updates für Ideen? Ja.

Daraus erstellt er eine To-do-Liste und schreibt sechs Feature-Spezifikationen mit eigenen IDs.

Jetzt bist du dran: das Review

Bevor es weitergeht, prüfst du jede Spezifikation. Sind das wirklich die richtigen Anforderungen? Fehlt etwas? Du kannst die Dateien direkt bearbeiten oder Claude um Änderungen bitten. In der Spezifikation zur Authentifizierung standen bei mir zum Beispiel auch Passwort-Reset, Logout und Edge Cases wie eine bereits registrierte E-Mail-Adresse.

Erst wenn alles passt, gibst du die Features frei. Dieser Schritt ist der wichtigste im ganzen Prozess. Was hier fehlt, baut später niemand.

Schritt 5: Technisches Design mit dem Solution Architect

Neue Session, neue Rolle. Ich rufe den Solution Architect auf:

Ich möchte bitte, dass du das Feature mit der ID PROJ-1 planst.

Er liest die Spezifikation, prüft die bestehende Architektur, die vorhandenen UI-Komponenten und die Supabase-Konfiguration. Dann entwirft er das technische Design. Für die Authentifizierung waren das alle nötigen Seiten (Login, Registrierung, E-Mail-Bestätigung, Passwort vergessen, Passwort zurücksetzen) mit ihren Elementen und technischen Entscheidungen, etwa Supabase Auth statt eines eigenen Login-Systems.

Auch er stellt Rückfragen, bei mir: Soll die App auf Deutsch oder Englisch sein? Gibt es schon ein Supabase-Projekt? Danach trägt er das Design in die Feature-Datei ein und gibt mir den Prompt für die nächste Rolle mit.

Schritt 6: Frontend und Backend entwickeln

Der Frontend Developer prüft zuerst die vorhandenen shadcn-Komponenten und die App-Struktur. Dann fragt er nach dem visuellen Stil, zum Beispiel modern und minimalistisch, verspielt oder Dark Mode, und nach Markenfarben. Hier kannst du eigene Hex-Codes mitgeben, Screenshots als Referenz hochladen oder über einen Figma MCP Server deine Figma-Designs übernehmen. Ich habe für das Beispiel die Standardpalette genommen.

Umgebungsvariablen eintragen

Nach der Umsetzung meldet der Frontend Developer, was noch fehlt, damit die App mit Supabase sprechen kann:

1. Umgebungsvariablen setzen. Im Template liegt eine .env.local.example. Du trägst dort die Projekt-URL und den öffentlichen Publishable Key aus Supabase ein (beides findest du in den Project Settings unter Data API und API Keys) und entfernst die Endung .example aus dem Dateinamen.
2. Supabase konfigurieren. Unter Authentication → URL Configuration trägst du die Site URL (zunächst localhost) und die Redirect URL ein, die Claude dir nennt.

Diese Werte trägst du selbst ein, nicht per Prompt.

Backend: Datenbank und Sicherheitsregeln

Bei der Authentifizierung hatte der Backend Developer wenig zu tun, das meiste übernimmt Supabase. Spannender wird es beim zweiten Feature, dem Einreichen von Ideen. Hier hat mir der Solution Architect sogar eine Reihenfolge vorgegeben: erst Backend, dann Frontend, weil die Datenbanktabelle existieren muss, bevor die Oberfläche darauf zugreifen kann.

Der Backend Developer hat dann:

• eine Tabelle ideas angelegt (ID, Titel, Beschreibung, Status, Ersteller, Erstellungs- und Bearbeitungszeitpunkt),
• Row Level Security eingerichtet,
• ein Rate Limit gesetzt: maximal 10 Ideen pro Stunde,
• die API-Routen zum Abrufen, Anlegen, Ändern und Löschen von Ideen gebaut,
• die Security Advisors von Supabase geprüft.

Row Level Security (RLS) legt auf Datenbankebene fest, wer welche Datensätze sehen und ändern darf. In unserem Fall: Alle eingeloggten Nutzer:innen sehen alle Ideen. Erstellen, bearbeiten und löschen dürfen sie aber nur ihre eigenen, außer Admins. Genau diese Regeln fehlen in vielen Vibe-Coding-Apps, und genau deshalb liegen dort Daten offen.

Dank MCP Server legt Claude Code Tabellen und Berechtigungen selbst an. Du musst nicht ins Supabase-Dashboard und dort Migrationsskripte ausführen. Im Table Editor kannst du aber jederzeit nachsehen, was angelegt wurde.

Schritt 7: Testen mit dem QA Engineer

Wenn ein Feature implementiert ist, teste ich es erst kurz selbst. Bei der Registrierung kam die Bestätigungs-E-Mail von Supabase an, und nach dem Klick landete ich eingeloggt auf dem Voting-Board. Dann übernimmt der QA Engineer in einer neuen Session:

Das Feature PROJ-1 ist fertig implementiert. Bitte teste alle Funktionen.

Er liest die Spezifikation, startet den Dev-Server und testet Registrierung, Login, Logout, Passwort-Reset, Session-Handling, Sicherheit, verschiedene Browser und mobile Ansichten. Den Testreport schreibt er in die Feature-Datei. Bei mir sah das Ergebnis für die Authentifizierung so aus:

• Akzeptanzkriterien: 20 von 20 bestanden
• Edge Cases: 8 von 10 bestanden
• Sicherheit: keine kritischen Probleme
• Bugs: vier, davon einer mittel und drei niedrig

Nicht jeder gemeldete Bug ist wirklich einer. Eine fehlende „E-Mail erneut senden“-Option ist eher ein neues Feature. Interessant war ein Sicherheitshinweis: Die Registrierung verrät, ob eine E-Mail-Adresse schon existiert. Damit könnte man herausfinden, ob eine bestimmte Person ein Konto hat. Ob du das änderst, ist eine Abwägung.

Hier bist du wieder als Entscheider gefragt. Ich habe den Bug mit falsch dargestellten Umlauten beheben lassen und den Rest bewusst zurückgestellt. Prüf die Ergebnisse außerdem immer selbst, damit auch dem QA Engineer nichts entgeht.

Schritt 8: Deployment mit dem DevOps Engineer

Zum Schluss hilft mir der DevOps Engineer, das Feature auf Vercel zu bringen. Er committet die Änderungen, pusht sie zu GitHub und schreibt mir eine Anleitung:

1. In Vercel Add New Project wählen und das GitHub-Repository importieren.
2. Die Umgebungsvariablen aus der lokalen .env.local in Vercel hinterlegen, also Supabase-URL und Key.
3. Auf Deploy klicken.

Danach schickst du Claude die Production-URL. Er prüft, ob alle Seiten laden, und erinnert dich an einen Schritt, den man leicht vergisst: In Supabase die Site URL und die Redirect URLs auf die neue Live-Domain umstellen. Sonst funktionieren Registrierung und Passwort-Reset in der Live-Version nicht. Am Ende markiert er das Feature in der Feature-Datei als deployed.

Ab jetzt reicht es, Claude um einen Push zu GitHub zu bitten. Vercel synchronisiert automatisch, und die neue Version ist online.

Der Kreislauf für jedes weitere Feature

Für jedes weitere Feature wiederholt sich derselbe Ablauf, jeweils in einer frischen Session:

1. Solution Architect: technisches Design (die Spezifikation existiert schon)
2. Backend Developer: Datenbank, Sicherheitsregeln, API
3. Frontend Developer: Oberfläche
4. Selbst testen, dann QA Engineer
5. DevOps Engineer: Deployment und Test der Live-Version

Beim Feature „Idee einreichen“ meldete der QA Engineer 14 von 15 bestandenen Akzeptanzkriterien und drei „Bugs“, die eher Feature-Wünsche waren, etwa ein fehlender Retry-Button bei Netzwerkfehlern. Das Feature war produktionsreif.

Fehler finden: Browser-Konsole, Netzwerk und Logs

Fehler passieren. Du kannst Claude Code aber viel mehr Informationen geben als „geht nicht“:

• Browser-Konsole: Rechtsklick → Untersuchen → Konsole. Dort tauchen meist die Fehlermeldungen auf. Kopier sie eins zu eins in den Chat.
• Netzwerk-Tab: Hier siehst du jede Anfrage an dein Backend, welche Daten gesendet werden und was zurückkommt. Jede Anfrage hat einen Statuscode. 200 heißt alles in Ordnung, 400er- und 500er-Codes bedeuten, dass etwas schiefgelaufen ist.
• Supabase-Logs: Über den MCP Server hat Claude Zugriff auf die Logs. Liegt der Fehler im Backend, bitte ihn ausdrücklich, dort nachzusehen.

Datenschutz nicht vergessen

Wenn deine App personenbezogene Daten verarbeitet, achte bei der Wahl von Datenbank-Region, Hosting und KI-Tools auf den Datenschutz. Und teile personenbezogene Daten nie ungeschützt in Prompts. Das ist keine Rechtsberatung, aber eine Grundregel, die ich in jedem Projekt einhalte.

Einordnung: Der Workflow macht den Unterschied

Claude Code allein macht aus einer Idee noch kein sicheres SaaS. Den Unterschied machen die Struktur drumherum: klare Spezifikationen mit Akzeptanzkriterien, getrennte Rollen mit schlankem Kontext, Sicherheitsregeln auf Datenbankebene, unabhängige Tests und dein Review an jeder Station.

Damit schließt du einen Großteil der typischen Fehler schon von vornherein aus. Je größer dein Produkt wird, desto wichtiger ist genau dieser feste Prozess: Jedes Feature läuft durch dieselben Phasen, und du behältst als Product Owner die Kontrolle, ohne selbst Code lesen zu müssen.