MVP-Checkliste: 12 Fragen bevor du anfängst zu bauen

MVP - Minimum Viable Product. Das klingt simpel, wird aber von den meisten falsch verstanden. Ein MVP ist kein halbfertiges Produkt - es ist die kleinstmögliche Version die deine Kernhypothese testet. Bevor du einen einzigen Code-Zeile schreibst, solltest du diese 12 Fragen beantworten können.

Die 12 MVP-Fragen

• 1. Welches spezifische Problem löst du? (Sei präzise - nicht "Zeitmanagement verbessern")
• 2. Für wen genau? (Nicht "alle" - ein konkretes Nutzerprofil)
• 3. Wie lösen sie das Problem heute? (Alternative zu deiner Lösung verstehen)
• 4. Warum ist deine Lösung besser? (USP klar formulierbar?)
• 5. Haben 5 echte Menschen bestätigt dass das Problem schmerzhaft ist?
• 6. Haben 3 dieser Menschen gesagt sie würden dafür zahlen?
• 7. Was ist der Eine Kern-Use-Case des MVP? (Nicht zwei, nicht drei - einer)
• 8. Was kannst du weglassen ohne dass der Kern-Use-Case leidet?
• 9. Wie misst du ob der MVP erfolgreich ist? (Konkrete Metriken)
• 10. In welchem Zeitraum kannst du den MVP bauen? (Wenn länger als 3 Monate: kürzen)
• 11. Wie kommst du an die ersten 10 Nutzer?
• 12. Was lernst du wenn der MVP scheitert?

MVP-Timeline: Vom Konzept zum Launch

Ein realistischer MVP-Zeitplan umfasst vier Phasen. Phase 1 ist die Validierung (1-2 Wochen): Problem-Interviews führen, bestehende Lösungen analysieren, Zahlungsbereitschaft testen. Phase 2 ist das Design (1 Woche): Wireframes für den Kern-Use-Case, User-Flow definieren, kein Pixel-perfektes Design - Funktionalität zählt. Phase 3 ist der Build (4-6 Wochen): Fokus auf den einen Use-Case, kein Feature-Schleichen, wöchentliche Demos mit echten Nutzern. Phase 4 ist Test und Iteration (2 Wochen): Erste Nutzer onboarden, Feedback sammeln, kritische Bugs fixen - aber keine neuen Features. Insgesamt also 8-11 Wochen vom ersten Gespräch bis zum Launch. Wenn dein Plan deutlich länger ist, baust du wahrscheinlich kein MVP mehr.

Tech-Stack für schnelle MVPs

Die Wahl des Tech-Stacks entscheidet mit darüber, wie schnell du vom Konzept zum funktionierenden Produkt kommst. Für MVPs hat sich eine Kombination bewährt: Next.js als Frontend-Framework liefert Server-Side-Rendering, API-Routes und schnelle Ladezeiten aus einer Codebasis. Supabase als Backend ersetzt eine komplette Server-Infrastruktur - Authentifizierung, Datenbank und Storage sind in Minuten aufgesetzt statt in Tagen. Vercel als Hosting-Plattform ermöglicht Deployments per Git-Push mit automatischem Preview für jede Änderung. Dieser Stack reduziert die Build-Phase von 4-6 Wochen auf teilweise 3-4 Wochen, weil du dich auf Produktlogik konzentrierst statt auf Infrastruktur. Wichtig: Wähle Technologien die dein Team beherrscht. Der schnellste Stack ist wertlos wenn das Team ihn erst lernen muss.

Der häufigste Fehler

Feature-Creep: das MVP wird immer größer weil jeder eine Idee hat die "unverzichtbar" klingt. Die Lösung: jedes Feature muss direkt der Kernhypothese dienen. Wenn nicht, kommt es in den Backlog - nach dem MVP.

Nach dem MVP: Wann skalieren

Der MVP ist live - aber wann lohnt es sich, mehr zu investieren? Es gibt klare Signale. Positiv: Nutzer kommen ohne Marketing zurück, die Retention nach 30 Tagen liegt über 20 Prozent, Kunden fragen aktiv nach weiteren Features, und der wichtigste Indikator - jemand zahlt tatsächlich dafür. Negativ: Nutzer melden sich an, kommen aber nie wieder, das Problem ist zwar real aber nicht schmerzhaft genug für eine Bezahllösung, oder du erreichst die Zielgruppe nur mit hohem Aufwand. Wenn die negativen Signale überwiegen, ist das kein Scheitern - es ist ein Ergebnis. Entweder pivotierst du die Lösung oder den Markt. Wenn die positiven Signale überwiegen, investiere gezielt: erst Stabilität und Performance, dann schrittweise neue Features die von echten Nutzern angefragt wurden.

Wann du fertig bist

Du bist fertig mit dem MVP wenn du deinen Kerntest durchgeführt hast und weisst ob die Hypothese stimmt. Nicht wenn du stolz bist auf das Produkt - wenn du validiert hast ob jemand dafür zahlt.