Mein AI-Coding-Workflow: So entwickle ich ein SaaS mit Claude Code

Viele scheitern beim Schritt vom Prototyp zur echten Anwendung, weil im Hintergrund unbemerkt eine aufgeblähte Codebasis entsteht, die weder sie selbst noch ihr Coding Agent mehr in den Griff bekommen. Oft bleibt dann nur der Neustart.

In diesem Artikel zeige ich dir meinen persönlichen Workflow für agentische Softwareentwicklung. Ich spiele ihn an einem echten Projekt durch: einem KI-gestützten Lebenslauf-Optimierer. Du siehst jede Phase, die Dokumente, die dabei entstehen, und warum ich sie so aufgebaut habe.

Warum Vibe Coding bei echten SaaS-Produkten an Grenzen stößt

Am Anfang ist die Euphorie groß. Du bekommst schnell vorzeigbare Ergebnisse. Je länger du aber an einer App entwickelst, desto mehr Stolpersteine tauchen auf, bis du irgendwann an einen Punkt kommst, an dem es nicht mehr weitergeht.

Dazu kommt: Stabilität und Sicherheit werden meist nur nach Gefühl beurteilt. Ob nicht doch irgendwo sensible Daten offenliegen, können die meisten gar nicht einschätzen. Für produktive Software brauchst du deshalb weiterhin bestimmte Fähigkeiten, Werkzeuge und Praktiken. Der Workflow unten ist das, was sich bei mir nach über 150 Softwareprojekten für die Arbeit mit Coding Agents bewährt hat.

Der Workflow im Überblick: Spec Driven Development

Statt einfach drauflos zu prompten, nutze ich Spec Driven Development. Das Prinzip: Bevor irgendetwas entwickelt wird, legen wir fest, was genau umgesetzt werden soll. Dafür zerlegen wir das Produkt in einzelne Features und schreiben zu jedem Feature eine Spezifikation, also ein Anforderungsdokument.

Danach durchläuft jedes Feature dieselben Phasen:

Mit Systemdesign ist nicht das optische Design gemeint, sondern wie die Umsetzung aussieht: Welche Seiten, Komponenten und Daten brauchen wir?

Für jede Phase habe ich in Claude Code einen eigenen Skill angelegt. Ein Skill ist eine ausführliche Anleitung, die Claude für eine bestimmte Aufgabe lädt: mit Ziel, Ablauf, Checklisten und Vorlagen für die Dokumente, die am Ende entstehen sollen.

Das Beispielprojekt: ein KI-Lebenslauf-Optimierer

Als Beispiel orientiere ich mich an einem bestehenden SaaS-Produkt namens Rezi. Dort erstellst du KI-gestützt Lebensläufe und optimierst sie auf konkrete Stellenanzeigen.

Du gibst eine Stellenanzeige und deinen bisherigen Lebenslauf ein, etwa aus LinkedIn oder als Upload. Die KI optimiert ihn auf diese Stelle, und ein Scoring zeigt dir jederzeit, wie gut er abschneidet und wo du nachbessern kannst. Dass das Geschäftsmodell funktioniert, zeigen die öffentlich verifizierten Umsatzzahlen von Rezi.

Vorbereitung: Projekt-Briefing und Prototyp

Das Projekt-Briefing

Zuerst überlege ich mir, was die Plattform alles können soll. Ich kippe meine Gedanken einfach in Claude und lasse daraus eine Markdown-Datei schreiben. Darin steht die grobe Idee: Funktionsumfang, Nutzer:innen, Monetarisierung, Integrationen, erste Gedanken zur Datenbankstruktur. Das Briefing muss nicht perfekt sein. Es ist der Startpunkt.

Der Prototyp in Claude Design

Früher habe ich an dieser Stelle Screens in Figma gebaut. Heute lasse ich mir in Claude Design einen Prototyp erstellen. Dort kann ich extrem schnell iterieren, ohne mir Gedanken über den Code zu machen, denn am Ende ist das nur eine einfache HTML-Datei mit etwas CSS.

Genau diese Experimente will ich mir später ersparen. Steht erst einmal das App-Gerüst, werden fundamentale Änderungen von Schritt zu Schritt schwieriger.

Bin ich mit dem Prototyp zufrieden, aktualisiere ich mein Projekt-Briefing. Erst dann startet der eigentliche Entwicklungsprozess mit Claude Code. Den Prototyp exportiere ich als eigenständige HTML-Datei und lege ihn in den Dokumentenordner des Projekts. Er dient als Vorlage für das Designsystem. Hast du ein anderes Designsystem vorbereitet, kannst du natürlich auch das verwenden.

Die Architektur der Anwendung

• Die App selbst besteht aus dem Client, also der Benutzeroberfläche mit allem, was Nutzer:innen sehen und anklicken, und einer Serverkomponente, die im Hintergrund die App-Logik übernimmt und externe Systeme anbindet.
• Supabase als Backend liefert die Authentifizierung mit Registrierung und Login, die Datenbank für Lebensläufe und Co. und einen Dateispeicher für Uploads. Dazu kommt Row Level Security: Datenbankregeln, die zum Beispiel sicherstellen, dass ich nur meine eigenen Lebensläufe sehe und nicht die anderer Nutzer:innen.
• Externe Dienste: Mistral für die KI-Analyse, Stripe für den Kauf von Credits und transaktionale E-Mails, etwa wenn das Guthaben nicht mehr reicht.
• GitHub dient als Cloudspeicher für den Code und als Deployment-Pipeline. Jede veröffentlichte Änderung geht automatisch an den Hosting-Anbieter und ist danach live.

Mein Setup: VS Code statt Desktop-App

Für die Entwicklung nutze ich nicht die Claude Desktop App, weil mir dort die Übersicht fehlt. Ich arbeite in einer echten Entwicklungsumgebung (IDE): Visual Studio Code, kostenlos und Open Source. Mit der Claude-Code-Erweiterung habe ich links alle Dateien, in der Mitte die geöffnete Datei, etwa eine Spezifikation, und rechts den Claude-Chat.

Mein Setup installiere ich mit einem einzigen Befehl in einen neuen Projektordner. Darin liegen der .claude-Ordner mit allen Skills für den Workflow und ein vorbereitetes Webprojekt auf Basis von Next.js. Aus meiner Sicht ist das aktuell das am besten geeignete JavaScript-Framework für KI-gestützte Softwareentwicklung.

Phase 1: Das Projekt initialisieren

Die Initialisierung läuft einmal pro Projekt. Ich starte den Initialisierungs-Skill und gebe ihm das Projekt-Briefing und den Prototyp mit. Claude startet daraufhin ein Discovery Interview: Er versucht, das gesamte Projekt zu verstehen, und stellt mir gezielt Fragen.

Dabei passiert eine ganze Menge:

• Datenschutzstrategie festlegen. Ich habe den Standard gewählt: ein echtes Produkt mit personenbezogenen Daten für die Öffentlichkeit, mit den üblichen Pflichten wie Datenschutzhinweisen.
• Designsystem einrichten, basierend auf dem Prototyp. Viele Fragen beantwortet der Prototyp schon selbst. Gefragt wurde ich nur noch, ob es einen Dark Mode geben soll.
• PRD schreiben. Das Product Requirements Document enthält das Projekt aus hoher Flughöhe: Vision, Zielgruppe, Scope, Erfolgskriterien, Rahmenbedingungen und was bewusst nicht dazugehört.
• Feature-Roadmap bauen. Aus Briefing und Interview leitet Claude einzelne Features ab.
• Grobes Datenmodell skizzieren. Die Tabellen und ihre Beziehungen. Die einzelnen Felder kommen später über die Spezifikationen dazu.
• App-Shell skizzieren. Das visuelle Grundgerüst: Navigation, Kopfbereich und alles, was auf allen Unterseiten gleich ist.
• Umgebungsstrategie klären. Läuft das Backend für die Entwicklung lokal, oder nutzt du je eine Cloud-Instanz für Test- und Produktivdaten?

Das Interview ist intensiv. Claude hat in meinem Briefing auch Widersprüche gefunden und direkt mit mir geklärt. Das Ziel ist ein gemeinsames Verständnis der Anwendung.

Was am Ende der Initialisierung steht

Claude hat mir das PRD zur Freigabe vorgelegt. Die Roadmap startet mit Konten und Authentifizierung, denn das große Sicherheitsthema soll zuerst stehen, bevor alles andere darauf aufbaut. Bei der KI-Integration hat Claude außerdem festgehalten, dass Namen, Adressen, Telefonnummern, E-Mail-Adressen und Geburtsdaten aus dem Lebenslauf entfernt werden müssen, bevor er an die KI geht.

Jedes Feature hat eine eigene ID, eine Kurzbeschreibung und eine Priorität. Fast alles hat Priorität P0, gehört also zum Kern des MVP. Nur der PDF-Export hat P1 bekommen und kann später folgen. Dazu kommt eine empfohlene Baureihenfolge, damit nichts gebaut wird, bevor die Grundlage dafür existiert.

Für die Entwicklung läuft Supabase bei mir lokal in einem Docker-Container. Darüber kann Claude per Supabase CLI die Datenstruktur anlegen und mit Testinhalten befüllen. Wie du so eine lokale Umgebung aufsetzt, zeige ich in der Anleitung zur Testumgebung für Claude Code.

Ein Detail am Rande: Claude hat keinen Zugriff auf meine lokale .env-Datei, in der meine Schlüssel liegen. Den lokalen Supabase-Schlüssel darf er kennen, meinen Mistral-Key aber nicht. Das sperre ich über das Berechtigungssystem von Claude Code. Wie das geht, steht in meinem Artikel zum Schutz deiner API-Keys.

Die Feature-Liste als Projektmanagement für Claude

Ein zentrales Dokument ist die Feature-Liste. Sie ist Claudes eigenes kleines Projektmanagement und hilft auch mir, den Fortschritt zu verfolgen. Jedes Feature hat dort einen Status, den Claude aktualisiert, sobald er einen Schritt abgeschlossen hat:

Der große Vorteil: Auch in einer frischen Session weiß Claude sofort, wo das Projekt steht. Nach der Initialisierung committe ich alles und starte für das erste Feature eine neue Session.

Phase 2: Die Spezifikation schreiben

Für die Spezifikation rufe ich den passenden Skill auf und gebe ihm die Feature-ID mit. Claude nimmt sich dieses eine Feature aus der Roadmap vor, schaut sich alles an, was bereits existiert, und führt wieder ein Discovery Interview, diesmal nur zu diesem Feature.

Beim Feature „Konten und Authentifizierung“ wurde ich zum Beispiel gefragt:

• Registrierung mit oder ohne E-Mail-Bestätigung? → Mit Bestätigungslink, damit klar ist, dass die Adresse existiert.
• Welche Felder hat das Registrierungsformular? → Nur E-Mail und Passwort.
• Ab wie vielen Fehlversuchen wird der Login gebremst? → Claudes Vorschlag: fünf Versuche in 15 Minuten, danach 15 Minuten Sperre.

Dieses Rate Limiting verhindert Brute-Force-Angriffe, bei denen jemand massenhaft Passwörter ausprobiert. Der Skill fragt solche Sicherheitsthemen von sich aus ab.

Was in der Spezifikation steht

Für jedes Feature entsteht ein eigener Ordner, in dem für jeden Schritt ein Dokument landet. Das erste ist die Spezifikation. Sie enthält:

• Abhängigkeiten, die erfüllt sein müssen, bevor das Feature gebaut werden kann.
• User Stories, also wer das Feature wofür nutzt.
• Out of Scope: Was bewusst nicht gebaut wird, etwa Login mit Google. Das verhindert, dass der Agent alles Mögliche dazu baut.
• Akzeptanzkriterien nach dem Muster „Angenommen, Wenn, Dann“ (im Englischen Given, When, Then).
• Edge Cases, also Sonderfälle, an denen die App brechen könnte.
• Offene Fragen und ein Decision Log, in dem jede meiner Antworten aus dem Interview protokolliert ist.

So sieht eine User Story aus:

Als Bewerber möchte ich mir mit E-Mail-Adresse und Passwort ein Konto anlegen,
damit mein optimierter Lebenslauf über mehrere Sitzungen erhalten bleibt.

Akzeptanzkriterien: der wichtigste Teil der Spec

Die Akzeptanzkriterien sind die wichtigste Sektion, denn Claude kann sie später selbst überprüfen, und du genauso:

Angenommen, ein abgemeldeter Besucher ist auf der Registrierungsseite.
Wenn er das Formular leer abschickt,
dann wird für jedes Pflichtfeld eine Validierungsmeldung angezeigt und kein Konto angelegt.

Auch der Datenschutz wird nicht als separate Compliance-Liste geführt, sondern als echtes Akzeptanzkriterium. Als Betreiber musst du anbieten, dass Nutzer:innen alle ihre Daten selbst löschen können:

Angenommen, ein eingeloggter Nutzer möchte sein Konto löschen.
Wenn er die Löschung bestätigt,
dann werden Konto, Profil, Lebensläufe, Zielstellen, Zuschnitte und Credit-Bewegungen gelöscht.
Ein Login ist danach nicht mehr möglich, und die E-Mail-Adresse ist wieder frei.

Die Spezifikation lese ich komplett durch und gebe sie erst dann frei.

Phase 3: Systemdesign und Architektur planen

Im nächsten Schritt übersetzt Claude die Spezifikation in einen technischen Entwurf, den du auch als Nicht-Entwickler lesen und freigeben kannst. Er enthält keinen Code, sondern:

• die Komponentenstruktur als Baum: welche Seiten und Komponenten es gibt, wie sie zusammenhängen und wie sie angeordnet sind,
• das Datenmodell des Features: welche Felder in der Datenbank tatsächlich gebraucht werden, hier etwa für die Tabelle profiles,
• Benutzerrollen und Zugriffsregeln, also wer was darf, zum Beispiel Unterschiede zwischen Admin und normalem Nutzer,
• den konkreten Missbrauchsschutz,
• die technischen Entscheidungen samt Begründung,
• die Abdeckung der Akzeptanzkriterien: Jedes Kriterium muss sich im Entwurf wiederfinden.

Ein Punkt, der mir wichtig ist: Ich habe den Context7 MCP Server verbunden. MCP (Model Context Protocol) ist eine Schnittstelle, über die Claude auf externe Systeme zugreift. Context7 liefert die aktuelle Dokumentation von Bibliotheken und Diensten. Beim Planen holt sich Claude so die aktuelle Supabase-Dokumentation, statt sich auf veraltete Trainingsdaten zu verlassen. Im Skill ist festgelegt, dass er Context7 nutzen soll, wenn der Server verbunden ist.

Phase 4: Der Aufgabenplan

Jetzt lasse ich Claude den Aufgabenplan schreiben. Dieser Schritt ist die Brücke zwischen Spezifikation, Systemdesign und dem eigentlichen Bauen. Claude zerlegt den Entwurf in eine geordnete Aufgabenliste.

Entscheidend ist dabei: Jede Aufgabe lässt sich einem Akzeptanzkriterium zuordnen, und jedes Akzeptanzkriterium muss von mindestens einer Aufgabe abgedeckt sein. Ein Kriterium ohne Aufgabe ist eine Lücke im Plan. Gleichzeitig grenzt der Plan den Umfang ein. Was keinem Kriterium dient, wird nicht gebaut. Das ist ein wirksamer Schutz gegen Over-Engineering.

Die Aufgaben werden in Ebenen sortiert, die strikt nacheinander abgearbeitet werden:

1. Fundament: Daten und Konfiguration, also Supabase mit den Tabellen und Feldern
2. Servergrundlage
3. Serverlogik, Authentifizierungsrahmen und Seiten
4. Feinschliff

Die feste Reihenfolge verhindert, dass zum Beispiel die Oberfläche gegen ein Datenmodell gebaut wird, das es noch gar nicht gibt. Innerhalb einer Ebene markiert Claude außerdem Aufgaben, die parallel laufen können, aber nur, wenn sie garantiert nicht dieselbe Datei anfassen. Bei der Umsetzung kann Claude dafür mehrere Subagents losschicken, also eigenständige Hilfsagenten, die Aufgaben parallel erledigen.

Phase 5: Die Umsetzung

Bin ich mit dem Plan zufrieden, schlägt der Skill direkt die nächsten Schritte vor: einen Feature-Branch erstellen, damit die laufende App unangetastet bleibt, die Schlüssel in der .env.local hinterlegen und dann mit der Umsetzung starten.

Claude arbeitet die Aufgabenliste Ebene für Ebene ab und prüft nach jeder Ebene gegen die Akzeptanzkriterien. Weicht die Realität vom Entwurf ab, soll er stoppen und melden, statt heimlich umzuplanen.

Am Ende fasst er zusammen, was er gebaut hat, und legt offen, welche Annahmen er treffen musste. In meinem Fall:

• Ein Akzeptanzkriterium konnte er nicht abdecken: das Rate Limit bei der Registrierung. Er hat es getestet, mehrere Anmeldeversuche durchgeführt und wurde nicht abgewiesen. Das ist eine Risikostelle, die sich aber direkt in der Supabase-Konfiguration schließen lässt.
• Eine veraltete Site-URL hat er gefunden und korrigiert.
• Er hat ein Platzhalter-Dashboard angelegt, weil man nach dem Login irgendwohin weitergeleitet werden muss. Das echte Dashboard kommt in einem späteren Feature.
• Er hat einen Farbton im Designsystem systemweit angepasst.

Im Browser entsprach die Oberfläche exakt dem Designsystem. Konto anlegen, Bestätigungsmail im lokalen Test-Postfach öffnen, Link klicken, eingeloggt: Das funktionierte auf Anhieb.

Phase 6: Qualitätssicherung mit Testbericht

Dass etwas im Browser funktioniert, heißt noch nicht, dass es fertig ist. Deshalb folgt der QA-Skill. Er arbeitet mit einer Vorlage für den Testbericht und macht Folgendes:

• Er prüft das Feature gegen jedes einzelne Akzeptanzkriterium und schaut, ob es fachlich passt.
• Er testet alle Edge Cases.
• Er schreibt Tests für die Code-Funktionen.
• Er geht zusätzlich wie ein Angreifer vor und versucht aktiv, Sicherheitslücken zu finden.
• Er hakt nur ab, was wirklich überprüft wurde, mit Nachweis. Was er nicht prüfen konnte, schlüsselt er klar auf.
• Er behebt selbst keine Fehler, sondern findet, dokumentiert und priorisiert sie.
• Am Ende steht ein eindeutiges Urteil: produktionsreif oder nicht.

Mein Ergebnis für das erste Feature: 26 von 27 aktiven Akzeptanzkriterien geprüft (eines hatte ich vorher gestrichen), 25 bestanden, eines durchgefallen, acht Edge Cases belegt, 51 neue Unit Tests, alle grün. Das Urteil trotzdem: nicht produktionsreif.

Der Grund waren die gefundenen Bugs. Der kritischste: Der Login nahm unbegrenzt viele Versuche an. Dazu kamen ein paar Bugs mittlerer Schwere. Alles steht im Testbericht im Feature-Ordner, mit abgehakten Kriterien, Ausrufezeichen bei fehlgeschlagenen oder ungeprüften Punkten und einem ausführlichen Fehlerbericht zu jedem Bug.

Jetzt schicke ich Claude mit dem Umsetzungs-Skill wieder los, um die Fehler zu beheben. Danach prüft der QA-Skill erneut. Das Feature steht so lange auf „In Review“, bis die QA es auf „Approved“ setzt.

Diese Trennung ist der Kern des Workflows. Claude kann bei der Umsetzung Dinge übersehen, die unabhängige Prüfung fängt das ab. Und du kannst den Testbericht mit den Akzeptanzkriterien abgleichen und das Feature abnehmen, ohne Code zu lesen.

Ein Prozess, der sich wiederholen und automatisieren lässt

Weil jeder Durchlauf gleich abläuft, lässt sich der Prozess gut automatisieren, etwa mit Loops, in denen Claude so lange iteriert, bis die Anwendung umgesetzt ist. Welche Befehle dabei helfen, beschreibe ich in meinem Artikel zu den Claude Code Befehlen, etwa /goal und /loop.

Phase 7: Deployment

Zum Schluss bringt der Deploy-Skill ein einzelnes Feature oder die gesamte App live. Dabei gelten klare Regeln:

• Durch kommen nur Features, die die QA bestanden haben. So landen keine kritischen Fehler im Livesystem.
• Vor dem Livegang wird der Zustand der App noch einmal geprüft und gesichert.
• Danach prüft der Skill die Produktivseite von außen und schaut, ob sich das System korrekt verhält.

Der Status in der Feature-Liste springt dann auf „Deployed“.

Nach dem Launch: Monitoring, Missbrauchsschutz und Datenschutz

Mit der Entwicklung ist es nicht getan. Eine App, an der du nichts mehr machen musst, gibt es nicht. Für den Betrieb brauchst du mindestens:

• Monitoring für Uptime und Fehler. Du willst sofort benachrichtigt werden, wenn Server- oder Browserfehler auftreten, damit du Fixes einspielen kannst, bevor viele Nutzer:innen in den Fehler laufen.
• Rate Limits für alle Authentifizierungs-Endpunkte und für alle Schnittstellen zu externen Systemen. Sie schützen deine App vor Missbrauch und deine Kosten, etwa bei KI-Aufrufen.
• Auftragsverarbeitungsverträge mit allen Diensten, die personenbezogene Daten für dich verarbeiten.
• Transparenz: Du musst mitteilen, welche Daten verarbeitet werden und wo.

Gerade der Datenschutz ist im deutschen Markt kein Nebenthema.

Warum ich kein fertiges Open-Source-Framework nutze

Viele Open-Source-Frameworks für Coding Agents basieren ebenfalls auf Spec Driven Development, manche auf Test Driven Development. Sie haben den gleichen Kern, und darauf baue ich auf: Ich übernehme Methodik, Kontextmanagement und Sicherheitspraktiken und kombiniere sie mit der Erfahrung aus meinen Projekten, zugeschnitten auf SaaS-Produkte von der Idee bis zum Betrieb.

Der entscheidende Unterschied liegt bei der Zielgruppe. Viele Frameworks setzen voraus, dass du aus Entwicklersicht beurteilen kannst, ob Codequalität und Output passen. Wer neu ins Agentic Engineering einsteigt, kann das oft noch nicht. Deshalb entstehen in meinem Workflow Spezifikationen, wie sie Produktteams ohnehin schreiben, die Leitplanken minimieren stille Annahmen und Over-Engineering, und am Ende steht ein Testbericht, den du ohne Entwicklerhintergrund abnehmen kannst.

Zusammenfassung

Der Workflow in Kurzform: Briefing und Prototyp, einmalige Initialisierung mit PRD und Feature-Liste, dann für jedes Feature Spezifikation, Systemdesign, Aufgabenplan, Umsetzung, unabhängige QA und Deployment. Der rote Faden sind die Akzeptanzkriterien. Sie entstehen in der Spezifikation, jede Aufgabe dient einem davon, und die QA hakt sie mit Nachweis ab.

Mit einzelnen Prompts kommst du bei einem Prototyp weit. Sobald du aber ein Produkt bauen willst, das echte Nutzerdaten verarbeitet und verkauft werden soll, brauchst du einen strukturierten Entwicklungsprozess, der jedes Feature durch dieselben Schritte führt. Wenn du mit Claude Code gerade erst anfängst, lies vorher meine Anleitung, wie du deine erste Web-App mit Claude Code entwickelst.