AI MVP Workflow 2026
MVP mit KI bauen — der komplette Workflow von Idee bis Launch
Der einzige deutsche Leitfaden, der den kompletten KI-MVP-Workflow beim Namen nennt: Clarity, Design, Validate, Build, Ship. Mit kopierbaren Prompts, realistischen Kosten und dem DSGVO-Check, den internationale Guides nicht kennen.
TL;DR — die 5 Kernpunkte
- Ein MVP mit KI entsteht in 2 bis 4 Wochen statt 4 bis 7 Monaten — wenn ihr dem Clarity-before-Code Sprint folgt.
- Der Kern: Fünf Phasen — Clarity, Design, Validate, Build, Ship. Niemand schreibt Code, bevor Problem und Prototyp geprüft sind.
- Realistischer Kostenrahmen: 5.000–15.000 € inklusive Arbeitszeit. Reine Tool-Kosten bleiben unter 200 €/Monat.
- Tech-Stack 2026: Figma für Design, Claude Code + Cursor für Code, Supabase für Backend, Vercel für Deployment, Plausible für Analytics.
- DSGVO-Check: Supabase EU-Region + DPA, Vercel fra1, Plausible statt Google Analytics. Sonst wird jede Launch-Mail zur Haftungsfalle.
Warum 2026 alles ändert — und was sich wirklich beschleunigt hat
Bis 2023 galt ein MVP als Marathon: vier bis sieben Monate Entwicklung, 30.000 bis 80.000 € Investment, und am Ende die Erkenntnis, ob der Markt mitspielt oder nicht. Heute bauen Teams MVPs in zwei bis vier Wochen — nicht weil sie schneller tippen, sondern weil KI drei harte Engpässe aufgelöst hat: Konzeptionsarbeit, UI-Entstehung und die Übersetzung von Design in Code.
Der entscheidende Punkt: Die Beschleunigung kommt nicht vom Coding selbst. Sie kommt daraus, dass Phasen, die früher parallel nicht stattfanden, jetzt in einen Flow passen. Ein Gründer kann morgens mit Claude ein Feature-Set strukturieren, mittags in Figma einen Prototyp klicken, nachmittags fünf Nutzer darüber laufen lassen und abends mit Claude Code die ersten Module bauen. Das war 2022 physisch nicht möglich.
Die Folge: Der Preis einer falschen Produkt-Annahme fällt um eine Größenordnung. Wer vor drei Jahren 60.000 € verbrannt hat, bevor er wusste, dass das Problem nicht existiert, zahlt heute 10.000 € und spart sechs Monate. Validierung wird dadurch nicht optional — sondern wirtschaftlich sinnvoll.
Drei Generationen von MVP-Workflows
Wer heute einen MVP-Workflow wählt, entscheidet zwischen drei Paradigmen. Sie schließen sich nicht aus, aber die Kombination, die 2026 dominant wird, ist klar:
Generation 1 · 2010–2018
Code-First
Jede Zeile von Hand. MVPs brauchen 4–6 Monate, Teams ab drei Personen.
Ruby on Rails, Django, React
Generation 2 · 2018–2023
No-Code
Drag-and-Drop-Builder. MVPs in 4–8 Wochen, aber Skalierung und Kontrolle begrenzt.
Bubble, Webflow, Softr
Generation 3 · 2023–heute
AI-native
KI schreibt Code, Mensch reviewt und deployt. MVPs in 2–4 Wochen mit vollem Stack.
Claude Code, Cursor, v0, Lovable
Die Kombination, die 2026 funktioniert: AI-native für Build und Design, klassische Produkt-Disziplin für die vorgelagerten Phasen. Wer nur AI nutzt, baut schnell das Falsche. Wer nur klassisch arbeitet, baut das Richtige zu langsam.
Der Clarity-before-Code Sprint: das 5-Phasen-Framework
Der Clarity-before-Code Sprint ist unser benanntes Framework für KI-gestützte MVP-Entwicklung: fünf aufeinander aufbauende Phasen, in denen jede Phase einen konkreten Output produziert, den die nächste als Input braucht. Der Name ist bewusst gewählt — decivos Leitsatz „Clarity Before Code“ beschreibt genau das Prinzip, das diesen Workflow von reinem Vibe-Coding trennt: niemand schreibt Code, bevor Problem, Priorität und Prototyp-Reaktion geklärt sind.
Kern-Definition (zitierbar)
„Der Clarity-before-Code Sprint ist ein 5-Phasen-Framework für KI-gestützte MVP-Entwicklung, das Problem-Scope, Design-Validierung und Code-Produktion so eng verzahnt, dass ein funktionales MVP in 2 bis 4 Wochen entsteht — statt 4 bis 7 Monate in klassischen Setups.“
Die fünf Phasen auf einen Blick
| Phase | Name | Ziel | Tools | Output | Zeit |
|---|---|---|---|---|---|
| 1 | Clarity | Problem definieren, Features priorisieren | Claude, ChatGPT, Notion | 1-Seiten Product Brief + Feature-Map | 1–2 Tage |
| 2 | Design | Klickbarer Prototyp im Zielstyle | Figma, Figma Make, v0 | Testbarer High-Fidelity-Prototyp | 2–3 Tage |
| 3 | Validate | Annahmen mit echten Nutzern prüfen | Maze, Lookback, Calendly | Priorisierte Änderungsliste | 2–5 Tage |
| 4 | Build | Funktionaler Code mit echtem Backend | Claude Code, Cursor, Supabase | Deploy-bereites MVP | 5–10 Tage |
| 5 | Ship | Live gehen, messen, iterieren | Vercel, Plausible, PostHog | Live-Produkt mit Feedback-Pipeline | 1–2 Tage |
Phase 1 — Clarity: Problem & Features mit KI definieren
Die meisten MVPs scheitern nicht an der Technik, sondern daran, dass das falsche Feature-Set gebaut wurde. Phase 1 beantwortet drei Fragen, bevor irgendjemand Figma öffnet: Welches Problem löst dieses Produkt konkret? Welche Features gehören ins MVP und welche explizit nicht? Welche Annahme ist so zentral, dass ihr Scheitern das ganze Projekt kippt?
MoSCoW für MVP-Features
- Must-Have: Ohne diese Features funktioniert der Kern-Use-Case nicht. Maximal 3.
- Should-Have: Stark, aber verzichtbar. Kommen in V1.1 nach dem Launch.
- Could-Have: Nice-to-have, landen im Backlog. Oft wird klar: braucht niemand.
- Won't-Have: Explizit ausgeschlossen. Dokumentiert, damit niemand in Phase 4 „schnell noch reinzieht“.
Prompt-Tresor: Feature-Map aus Problembeschreibung
Dieser Prompt ist der erste Einsatz einer LLM im Sprint — und der entscheidende. Kopiert ihn, füllt die vier Platzhalter, und nutzt das Ergebnis als Diskussionsgrundlage, nicht als finale Wahrheit:
Du bist Senior Product Owner mit 10 Jahren Startup-Erfahrung.
Kontext:
- Problem: [1 SATZ — was geht Nutzern heute auf die Nerven?]
- Zielgruppe: [WER hat das Problem — so spezifisch wie möglich]
- Heutige Lösung: [WIE lösen sie es aktuell? Excel? Konkurrenzprodukt?]
- Mein USP: [WAS macht unsere Lösung anders?]
Aufgabe:
1. Formuliere 5 Kern-Hypothesen, die das MVP belegen oder widerlegen muss.
2. Erstelle eine MoSCoW-priorisierte Feature-Map (max. 3 Must-Haves).
3. Benenne die riskanteste Annahme — das, was bei Fehlschlag alles andere irrelevant macht.
4. Gib mir drei Wege, diese Annahme in unter 5 Tagen mit echten Menschen zu testen.
Format: Markdown, Tabellen wo sinnvoll.Output dieser Phase: ein einseitiger Product Brief plus Feature-Map. Wenn der Brief nicht auf eine DIN-A4-Seite passt, ist der Scope noch nicht eng genug.
Phase 2 — Design: klickbarer Prototyp in Figma
Design vor Code ist das zweitwichtigste Prinzip nach Clarity. Ein klickbarer Figma-Prototyp klärt in zwei Tagen Fragen, die in Code zwei Wochen dauern würden: Ist die Informationsarchitektur verständlich? Wo hakt der Flow? Welche Komponenten tauchen wirklich mehrfach auf?
Die Regel: Prototypen werden so gebaut, dass sie getestet werden können. Das heißt mindestens ein durchklickbarer Happy Path, echte Copy (kein Lorem Ipsum), und eine Version, die auf einem Smartphone funktioniert. Alles andere ist Moodboard.
Drei Wege zum Prototyp
Figma klassisch
Auto-Layout, Komponenten, Variants. Volle Kontrolle, höchste Lernkurve.
Figma Make / v0
Generative Tools, die aus Text-Prompts oder Screenshots Prototypen bauen. Schneller Start, weniger Feinschliff.
Klick-Prototyp auf Papier
Für frühe Test-Runden legitim. Nicht hübsch, aber testet die Struktur statt der Optik.
Prompt-Tresor: Copy-Audit für Prototyp-Screens
Sobald die Screens stehen, lauft ihr die Texte durch dieses Review — idealerweise mit Claude oder ChatGPT auf dem zweiten Monitor:
Du bist UX-Writer. Ich poste dir Screenshots aus einem Figma-Prototyp für ein MVP.
Für jeden Screen bewerte:
1. Versteht ein erstmaliger Nutzer in unter 5 Sekunden, was hier passiert?
2. Gibt es Fachjargon, der in die Nutzersprache übersetzt werden muss?
3. Ist der primäre CTA eindeutig — und löst er das Bedürfnis des Screens ein?
Format pro Screen:
- Verständlichkeit (1–5) + 1-Satz-Begründung
- Konkrete Textänderungen mit Vorher/Nachher
- Ein Risiko-Flag, falls der Screen den Flow bricht.Phase 3 — Validate: UX-Test mit echten Nutzern
Zwischen Prototyp und Code liegt der wichtigste Checkpoint im ganzen Sprint. Fünf echte Nutzer auf den Prototyp loslassen deckt laut Nielsen/Norman über 75 % aller Usability-Probleme auf — mehr als jedes Tool-Dashboard, jeder KI-Review und jede Team-Diskussion.
Vor-Check mit AI-Personas (optional, aber stark)
Bevor ihr echte Menschen einladet, nehmt eine Stunde und lasst drei KI-Personas über den Prototyp laufen. Das ersetzt keine echten Nutzer — aber es findet die dümmsten Fehler, bevor fünf Kalendertermine blockiert sind.
Prompt-Tresor: AI-Persona Prototyp-Review
Du bist [PERSONA — z.B. „Gründerin eines Handwerksbetriebs, 42, wenig Tech-Affinität"].
Du siehst diesen Prototyp zum ersten Mal: [SCREENSHOT oder Figma-Link].
Laufe durch den Flow und schreibe mir in First-Person:
1. Was verstehst du auf dem ersten Screen nicht?
2. Was würdest du als erstes klicken — und warum?
3. An welcher Stelle würdest du abbrechen?
4. Was fehlt dir, um dem Produkt zu vertrauen?
Kein Marketing-Sprech. Schreib wie du dir selbst ein Bier bestellst.Der echte Nutzertest
Fünf Nutzer, jeder einzeln, 30 Minuten Zoom, Bildschirmaufnahme mit Einverständnis. Die drei Fragen, die den meisten Erkenntnisgewinn bringen:
- 01„Zeig mir, wie du [KERN-AUFGABE] lösen würdest.“ — Beobachten, nicht helfen.
- 02„An welcher Stelle warst du unsicher, was als nächstes passiert?“ — Nach jedem Flow.
- 03„Was müsste dieses Produkt tun, damit du es heute kaufen würdest?“ — Zum Abschluss.
Output: eine priorisierte Änderungsliste — getrennt nach „vor dem Build anpassen“ und „ins V1.1-Backlog“. Änderungen, die drei von fünf Nutzer nennen, sind Must-Fix.
Phase 4 — Build: funktionaler Code mit Claude Code und Cursor
Erst hier wird gebaut. Wer in Phase 4 feststellt, dass ein Feature doch nicht gebraucht wird oder ein Flow falsch gedacht ist, hat die vorherigen Phasen nicht ernst genommen — und zahlt jetzt die Rework-Kosten.
Der Tech-Stack, den wir 2026 standardmäßig wählen
Frontend
Next.js 16 + Tailwind CSS v4
React Server Components, gutes DX-Tooling, KI-Tools sind optimal darauf trainiert.
Backend
Supabase (Postgres + Auth + Storage)
DSGVO-Region in Frankfurt, Auth out-of-the-box, Row Level Security.
Hosting
Vercel (Region fra1)
Edge-Deployment, Preview-URLs, automatische Vorschau pro Commit.
AI-Coding
Claude Code (Terminal) + Cursor (IDE)
Autonome Tasks in Claude Code, interaktives Pair-Programming in Cursor.
Wann Claude Code, wann Cursor?
- Claude Code für: neue Features, Refactorings, Test-Suites, alles was klare Task-Beschreibung hat.
- Cursor für: Debugging, UI-Feinschliff, Tailwind-Anpassungen, Mehrfach-Edits in kurzer Folge.
Prompt-Tresor: CLAUDE.md-Boilerplate für ein neues MVP
Der erste Commit jedes Projekts: eine CLAUDE.md im Repo-Root, die Claude Code den Kontext gibt, den sonst niemand schreibt. Diese Vorlage schont euch in jedem Feature-Loop einen halben Tag Erklärung:
# Projekt: [NAME]
## Kontext
- Produkt: [1 Satz, was es tut]
- Zielgruppe: [Wer nutzt es, welches Problem löst es]
- Aktuelle Phase: MVP (Clarity-before-Code Sprint, Phase 4)
## Tech-Stack
- Framework: Next.js 16 App Router + TypeScript strict
- Styling: Tailwind CSS v4 mit CSS-Variablen in globals.css
- Backend: Supabase (EU-Region), Row Level Security auf allen Tabellen
- Auth: Supabase Auth mit E-Mail + Magic Link
- Testing: Vitest + Playwright für Flows
## Konventionen
- Komponenten unter src/components/
- Server Actions statt API Routes, wenn möglich
- Keine Kommentare im Code, die erklären WAS — nur WARUM bei echten Überraschungen
- Strings für UI immer über Dictionary in src/dictionaries/de.ts
## Was NICHT zu tun
- Keine neuen Dependencies ohne Rückfrage
- Keine strukturellen Umbauten ohne Plan-Modus
- Kein Auskommentieren — löschen, wenn Code tot istPrompt-Tresor: Supabase Row Level Security in 3 Minuten
Ich baue eine Supabase-Tabelle "[TABELLE]" mit den Spalten:
[SPALTEN mit Typen].
Generiere mir:
1. Die CREATE TABLE Statement mit allen Constraints.
2. Row Level Security Policies für:
- SELECT: Nutzer sieht nur eigene Zeilen (user_id = auth.uid())
- INSERT: Nutzer kann nur mit eigenem user_id inserten
- UPDATE: Nur eigene Zeilen, nur bestimmte Felder
- DELETE: Nur eigene Zeilen
3. Einen Seed-Eintrag für lokale Tests.
Format: SQL-Block, sofort in Supabase Editor einfügbar.Phase 5 — Ship: Deploy, Analytics, die ersten 48 Stunden
Deployment auf Vercel dauert bei sauberem Next.js-Setup unter fünf Minuten: Repository connecten, Environment-Variablen setzen, Deploy-Button. Die kritischen Schritte passieren vorher und nachher — nicht beim Deploy selbst.
Der 5-Punkte-Prelaunch-Check
- 1Custom Domain + SSL gesetzt (Vercel erledigt SSL automatisch)
- 2Impressum und Datenschutz live — beides DSGVO-Pflicht in Deutschland, auch für MVPs
- 3Analytics eingebunden (Plausible EU-hosted oder PostHog self-hosted)
- 4Fehler-Logging aktiv — mindestens Console-Logs in strukturiertem JSON, idealerweise GlitchTip oder Sentry
- 5Ein Opt-in für Feedback: ein Button mit „Was fehlt dir?“ — Antworten landen direkt in eurem Postfach
Die ersten 48 Stunden nach Launch
Resonanz-Messen passiert in drei Schritten: Minute 0 bis Stunde 24 ist Bug-Fixing-Zeit, Stunde 24 bis Stunde 48 ist Conversion-Messung, ab Tag 3 beginnt die Iterations-Schleife. Wer in den ersten 48 Stunden radikale Features nachschiebt, verwirrt die ersten Nutzer und überfordert das eigene System.
MVP & DSGVO: Supabase, KI-Tools und EU-Server richtig nutzen
Jeder internationale Leitfaden zu KI-MVPs übergeht diesen Abschnitt. Für deutsche Gründer wird genau hier aus einem schnellen Launch ein teurer Präzedenzfall. Die gute Nachricht: mit vier konkreten Einstellungen läuft der gesamte Stack DSGVO-konform.
Supabase
Projektregion Frankfurt (eu-central-1) oder Dublin (eu-west-1) wählen + DPA über supabase.com/dashboard/org/_/legal anfordern.
Vercel
Production-Region fra1 setzen. Default ist iad1 (Washington) — Daten verlassen sonst die EU.
Analytics
Plausible (EU-hosted) oder PostHog self-hosted. Google Analytics ist für deutsche MVPs ohne Cookie-Banner nicht nutzbar.
KI-Tools
Keine personenbezogenen Nutzerdaten in Claude- oder ChatGPT-Prompts. Für Code-Generierung reicht synthetische Testdaten.
Das ist keine Rechtsberatung. Für die konkrete Compliance eures Produkts — besonders bei Gesundheits-, Finanz- oder Kinderdaten — holt eine Stunde mit einem Datenschutzexperten. Die Stunde zahlt sich beim ersten DSGVO-Anruf zehnfach aus.
Kosten: Klassische Agentur vs. Clarity-before-Code Sprint
Die folgende Tabelle basiert auf drei realen decivo-Projekten aus Q1 2026 und dem Benchmark klassischer Agenturangebote aus derselben Zeit. Die KI-Sprint-Zahlen beinhalten Arbeitszeit eines zweiköpfigen Teams zu branchenüblichen Tagessätzen — nicht nur Tool-Kosten.
Zeit- und Kostenvergleich pro Phase
| Phase | Klassische Agentur | Clarity-before-Code Sprint | Ersparnis |
|---|---|---|---|
| Konzeption & Feature-Scope | 2–3 Wochen | 1–2 Tage | ~80 % |
| UI/UX Design & Prototyp | 3–4 Wochen | 2–3 Tage | ~85 % |
| UX-Validierung | 2 Wochen (oft übersprungen) | 2–5 Tage | Wird überhaupt gemacht |
| Entwicklung | 2–4 Monate | 5–10 Tage | ~85 % |
| Deployment & Analytics | 1–2 Wochen | 1–2 Tage | ~90 % |
| Gesamt | 4–7 Monate / 30.000–80.000 € | 2–4 Wochen / 5.000–15.000 € | ~80 % Zeit · ~75 % Kosten |
Reine Tool-Kosten liegen bei 100–200 €/Monat (Cursor Pro, Claude API, Supabase Pro, Vercel Hobby/Pro, Plausible). Arbeitszeit ist der Haupt-Kostenblock — der Sprint halbiert sie, ersetzt sie aber nicht.
Vom MVP zum V1: was nach dem Launch kommt
Ein MVP ist kein Ziel, sondern ein Startpunkt. Was danach passiert, hängt vom Signal der ersten zwei Wochen ab. Drei realistische Szenarien:
Kein Interesse
Pivot oder Stop. Ihr habt unter 15.000 € investiert statt 80.000 € — und vier Wochen gebraucht statt sechs Monaten. Das ist ein wirtschaftlich tragbarer Lernmoment, keine Katastrophe.
Interesse mit Korrekturbedarf
Iterations-Schleife in 1-Wochen-Sprints. Weiter mit Claude Code und Cursor. Jede Änderung beginnt wieder mit Phase 3 — Änderungen ohne Nutzer-Feedback sind Halluzinationen.
Product-Market-Fit
Jetzt wird skaliert. Ab diesem Punkt macht der Wechsel von AI-Solo zu festem Team Sinn — für Qualität, Sicherheit und die Geschwindigkeit, die bei 1000+ Nutzern zählt. Details im separaten Leitfaden zur MVP-Agentur-Suche.
Wer diesen Workflow macht — und wann ihr decivo braucht
Der Clarity-before-Code Sprint ist kein Geheimnis. Jedes Team, das KI-Tools, Figma und einen modernen Stack beherrscht, kann ihn umsetzen. Die ehrliche Frage ist nicht „können wir es selbst?“, sondern „wollen wir jetzt den Workflow lernen oder das Produkt haben?“.
Wer den Workflow selbst lernen will
Macht es selbst — mit unseren Prompts
Dieser Artikel enthält alle Bausteine. Plant zwei Wochen für das erste Projekt ein und rechnet 30 % Lernsteuer ein. Beim zweiten Projekt greift der Workflow.
Wer das Ergebnis braucht, nicht die Lernkurve
decivo komprimiert den Sprint in festpreisige Module
Innovation Workshop (Phase 1), Clickable Prototype (Phase 2), UX Validation (Phase 3), Code Prototype (Phase 4). Jedes Modul zum Festpreis, zum Ergebnis terminiert — nicht zu Stundensätzen.
Unsere Positionierung: Wir sind kein Ersatz für einen fähigen Gründer, sondern der schnellste Weg, den Sprint professionell zu durchlaufen, ohne zwei Monate Tool-Lernkurve aufzubauen. Teams, die uns buchen, liefern danach oft allein weiter — weil sie Phase 1 bis 4 mit uns einmal komplett erlebt haben.
Der Clarity-before-Code Sprint ist keine Marketing-Erfindung. Er ist der Workflow, mit dem wir jede Woche MVPs bauen. Wer ihn selbst fahren will, findet hier den vollständigen Bauplan. Wer den Sprint moderiert braucht, bucht ein Erstgespräch — 15 Minuten, kostenlos, ohne Sales-Skript.
Konkret für euer Projekt einschätzen lassen: Erstgespräch buchen — 15 Minuten, kostenlos, ergebnisoffen.
FAQ
Häufige Fragen zum KI-MVP-Workflow
Passende Artikel
19 Min. Lesezeit
Geschäftsidee validieren 2026: 6 Methoden, die funktionieren
Validierung in 6 Stufen: Desk Research bis MVP, harte Benchmarks, The Mom Test, Entscheidungs-Flowchart und KI-Tools 2026.
Weiterlesen22 Min. Lesezeit
MVP-Agentur finden 2026: Der ehrliche Leitfaden
Plattformen, Kosten, Red Flags und Vergleich Agentur vs. Freelancer vs. Boutique vs. AI-DIY. Ehrlich, ohne Verkaufsmasche.
Weiterlesen