Von null auf MVP in 2 Wochen: Wie wir ScopeFlow mit Vibe Coding gebaut haben

Ein MVP (Minimum Viable Product) ist die kleinstmögliche Version eines Produkts, die echten Nutzern echten Wert liefert – und gleichzeitig validiert, ob die Grundannahmen stimmen. Nicht die kleinstmögliche Version, die man zeigen kann. Die Version, die das Kernproblem löst.

Das klingt einfach. In der Praxis ist die größte Herausforderung nicht die Technik – es ist die Entscheidung, was weglassen bedeutet.

Hier ist, wie wir es gemacht haben.

Die Ausgangssituation: Ein konkretes Problem, kein vages Feature

ScopeFlow entstand nicht aus einer Produktstrategie-Session. Es entstand aus einem eigenen Problem: Scope Creep kostet uns und unsere Freelancer-Kunden Geld und Nerven. Bestehende Tools (Projektmanagement-Software, Google Docs, Vertragsvorlagen) lösen das Problem nicht gut genug.

Das ist der beste MVP-Ausgangspunkt: ein spezifisches Problem, das ihr selbst habt und für das keine vorhandene Lösung wirklich passt.

Woche 1: Struktur vor Code

Tag 1–2: Figma zuerst

Kein Code, bevor das Interface klar ist. Wir haben in Figma den Kern-Flow skizziert: Wie sieht ein Nutzer seinen aktuellen Projekt-Scope? Wie fügt er eine Leistung hinzu? Wie markiert er eine Scope-Erweiterung als Change Request?

Keine vollständigen Designs – grobe Wireframes, die den Fluss abbilden. Dieser Schritt hat uns wahrscheinlich 3–4 Tage Entwicklungszeit gespart, weil wir nicht mittendrin die Richtung geändert haben.

Tag 3–4: Architektur mit Claude planen

Nicht in Cursor eingesprungen, sondern zuerst Claude gefragt: "Hier ist unser Interface-Flow. Welchen Stack würdest du für diesen Anwendungsfall empfehlen? Was sind die Trade-offs?"

Claudes Empfehlung und Begründung:

• Next.js 14 (App Router): Server-Components für Performance, gutes Ökosystem
• shadcn/ui: Keine Dependency, direkt im Code, vollständige Kontrolle
• Supabase: Auth, Datenbank, Row-Level-Security out of the box – kein Backend von null aufbauen
• Claude API: Für KI-Funktionen direkt integrierbar

Wir haben diese Empfehlung hinterfragt und zwei Alternativen diskutiert. Am Ende war Next.js + Supabase der klare Favorit für unsere Anforderungen.

Tag 5–7: Grundgerüst mit Cursor

Cursor-Prompt für den Start: "Erstelle ein Next.js 14 Projekt mit App Router, TypeScript, Tailwind, shadcn/ui. Integriere Supabase für Auth. Erstelle die Datenbankstruktur für Projekte, Leistungen und Change Requests basierend auf diesem Schema: [Schema einfügen]."

Das Ergebnis war nicht perfekt – aber es war ein funktionierendes Grundgerüst in einem Tag. Mit manuellem Setup hätte ich drei Tage gebraucht und wäre mehrfach steckengeblieben.

Woche 2: Iteration und erste echte Nutzer

Tag 8–10: Kern-Features implementieren

Die drei Funktionen, ohne die ScopeFlow kein MVP ist:

1. Projekt anlegen mit Leistungsumfang
2. Change Request dokumentieren und dem Kunden zeigen
3. Freigabe-Workflow (Kunde bestätigt oder lehnt ab)

Alles andere – Dashboard, Statistiken, Templates, Integrationen – wurde für die nächste Version zurückgestellt. Bewusst und schriftlich.

Tag 11–13: Feedback von drei echten Personen

Nicht beta.warteliste@beliebige-domain.com. Drei Personen, die wir kennen, die das Problem haben: zwei Freelancer-Kollegen, ein Agenturinhaber.

Das Feedback war konkret und wertvoll:

• Der Change-Request-Flow war zu viele Klicks
• Die E-Mail-Benachrichtigung an Kunden fehlte (war nicht geplant, wurde sofort priorisiert)
• Der Begriff "Leistungsumfang" war unklar – "Scope" war tatsächlich verständlicher

Alle drei Punkte wurden in zwei Tagen umgesetzt.

Tag 14: MVP live

Nicht perfekt. Nicht vollständig. Aber funktionierend und für echte Nutzung bereit.

Die ehrlichen Learnings

Shipping ist ein Skill, kein Zustand. Das Gefühl "noch nicht fertig" verschwindet nie von selbst. Man muss entscheiden, wann gut genug gut genug ist.

Als Designer bauen hat strukturelle Vorteile. Ich habe keine Zeit damit verbracht, einem Entwickler zu erklären, warum ein Hover-State wichtig ist oder wie das Empty State aussehen soll. Design und Implementierung liefen bei mir parallel.

Technisches Grundverständnis ist eine Voraussetzung, keine Option. Vibe Coding ohne jede technische Basis funktioniert für einfache Prototypen. Für echte Produkte braucht man genug Verständnis, um KI-Output zu bewerten und Fehler zu debuggen.

MVPs definieren echte Bedürfnisse. Alle drei Personen, die wir befragten, nutzten Features anders als erwartet. Das hätte kein Figma-Prototype gezeigt – dafür braucht es echte Interaktion mit einem echten Produkt.

Stack und Kosten des MVPs

---

FAQ: MVP bauen mit Vibe Coding

Wie lange dauert ein MVP wirklich? Das hängt stark vom Scope ab. Unser ScopeFlow-MVP hatte einen klar definierten Kern-Flow und 2 Wochen Vollzeit-Einsatz. Für ein komplexeres Produkt oder bei Teilzeit-Einsatz: 4–8 Wochen sind realistisch.

Was gehört in ein MVP – was nicht? Ins MVP gehört: der eine Kern-Flow, der das Hauptproblem löst. Nicht ins MVP gehören: Dashboard-Statistiken, Integrationen, erweiterte Filterung, Teamfunktionen, Mobile-Optimierung (außer das ist das Kernprodukt). Alles, was sich nach "nice to have" anfühlt, ist für v2.

Next.js oder andere Frameworks für MVPs? Next.js mit Supabase ist ein sehr gutes MVP-Setup für webbasierte SaaS-Produkte. Für einfachere Tools ist auch Astro oder plain React mit Firebase denkbar. Für Designer ohne JavaScript-Grundkenntnisse ist Webflow + No-Code-Backend ein valider Einstieg.

Wie validiere ich ein MVP ohne große Nutzerbasis? Mit 3–5 Personen, die das Problem wirklich haben und bereit sind, ehrliches Feedback zu geben. Quantitative Daten kommen später. In der MVP-Phase zählen qualitative Insights.

---

Ihr habt eine Produkt-Idee und wollt wissen, wie ein strukturierter Weg vom Problem zum ersten MVP aussieht? Wir helfen bei der Planung: hallo@betaform.io