MVP in 8 Wochen — was rein, was raus.

Wenn ein Gründer sagt „wir bauen unser MVP in sechs Monaten", dann ist das kein MVP — das ist ein Vollprodukt, getarnt als MVP. Ein echtes MVP — Minimum Viable Product — ist die kleinste Version, die ein Kunde tatsächlich kauft und nutzt. Nicht die kleinste Version, die der Gründer für „präsentabel" hält. Nicht die kleinste Version, mit der man sich auf einer Konferenz zeigen kann. Sondern die kleinste Version, für die jemand bezahlt.

Und für die meisten B2B-Software-Ideen lässt sich das in acht Wochen bauen. Nicht weil der Anspruch sinkt, sondern weil die Tools 2026 das Bauen beschleunigen — und weil Scope-Disziplin der entscheidende Hebel ist, nicht die Technologie.

Wir haben in den drei V1-Portfolio-Unternehmen — xpansio, Hey Listen, HireBotIQ — alle MVPs in unter zwölf Wochen live gebracht. Die meisten in acht. Hier ist die Mechanik, die das möglich macht.

Die 8-Wochen-Struktur

Woche 1 — Scope und Pre-Sales

Die erste Woche geht nicht in Code — sie geht in Klärung. Welches Problem löst das MVP konkret? Für wen? In welcher Form? Was muss zwingend dabei sein, was bewusst nicht? Diese Fragen werden nicht in einem Workshop beantwortet — sie werden in echten Kundengesprächen geklärt.

In Woche 1 sind drei bis fünf Gespräche mit potenziellen Kunden Pflicht. „Wenn das Produkt X tut und Y kostet — würden Sie das kaufen?" Diese Frage liefert ehrliche Antworten. Wenn drei von fünf sagen „Ja, das würde ich vermutlich kaufen, wenn es funktioniert", dann ist die Idee gut genug für einen Build. Wenn fünf von fünf sagen „kommt drauf an" oder „interessant, aber...", dann ist das Briefing noch nicht scharf genug.

Am Ende von Woche 1: ein klares Scope-Dokument auf einer Seite, mit drei bis fünf vorgemerkten Kunden, die das Produkt bei Launch kaufen wollen. Ohne diese Vorab-Validierung baut man im Blindflug.

Wochen 2 bis 7 — Bauen

Sechs Wochen für den Bau. Das ist der Kern. Wer hier länger braucht, hat entweder den Scope nicht eng genug gehalten oder den falschen Stack gewählt. Sechs Wochen heißt: durchschnittlich ein bis zwei wesentliche Features pro Woche fertig, getestet, deployed, von einem internen Tester durchgespielt.

Der wichtigste Disziplin-Punkt in dieser Phase ist Scope-Schutz. Jede Woche kommen aus den Kundengesprächen oder aus eigenen Überlegungen Wünsche dazu: „Wäre es nicht super, wenn wir auch X hätten?" Antwort in 95 Prozent der Fälle: Ja, das wäre super. Aber nicht für das MVP. Aufnehmen in eine V2-Liste, weiter bauen.

Woche 8 — Launch und erste Kunden

Die letzte Woche ist nicht „Polishing" — sie ist Go-Live. Die Kunden, die in Woche 1 vorgemerkt wurden, werden jetzt aufgenommen, geschult, ins Produkt geführt. Erste Rechnungen werden gestellt. Erste Bug-Reports werden bearbeitet.

Wer in Woche 8 keine zahlenden Kunden hat, hat kein MVP — er hat ein Demo-Produkt. Das ist der entscheidende Test: Können die ersten Kunden mit dem Produkt arbeiten und sind sie bereit, dafür Geld zu zahlen? Wenn ja: das MVP funktioniert, jetzt kommt die V2. Wenn nein: ehrlich analysieren, woran es scheitert — meist nicht an Features, sondern am Wert-Versprechen.

Scope-Disziplin — was zwingend rein muss, was rigoros raus

Was rein muss

Ein MVP braucht genau das, was nötig ist, damit ein Kunde das Versprechen bekommt, das er kauft. Wenn das Versprechen ist „automatisierte Lead-Qualifizierung im Vertrieb", dann muss das MVP genau das tun: Leads aufnehmen, qualifizieren, an den Vertrieb übergeben. Mit minimal akzeptabler Genauigkeit, mit minimal akzeptabler UX.

Konkret in den meisten B2B-Software-MVPs: ein einfaches Login, ein einziger Hauptworkflow, eine grundlegende Stripe-Anbindung für Payment, eine basale E-Mail-Notification (über Resend oder Postmark), ein einfaches Admin-Dashboard für den Operator. Das ist es.

Was rigoros raus muss

Was im MVP definitiv nichts zu suchen hat: User-Profile mit Foto-Upload und Bio. Settings-Page mit 30 Optionen. Customization-Möglichkeiten („User soll Theme wählen können"). Mobile App parallel zur Web-App. Eigenes Onboarding-Tutorial mit interaktiven Schritten. Mehrsprachigkeit, wenn der erste Markt deutschsprachig ist. Komplexes Permission-System mit Rollen-Hierarchien.

Jedes dieser Features fühlt sich an wie „brauchen wir doch eigentlich". In der Praxis: Sie kosten zwei bis vier Wochen Bauzeit pro Stück, und die ersten Kunden brauchen sie nicht. Sie können in V2 bis V5 nachgereicht werden, wenn die Roadmap durch echtes Kundenfeedback geklärt ist.

Die „Nein"-Disziplin

Der wichtigste Skill in der MVP-Phase ist „Nein" sagen — gegenüber Kunden, gegenüber Co-Foundern, gegenüber sich selbst. Jedes „Ja" zu einem zusätzlichen Feature ist ein „Nein" zu einer früheren Auslieferung. Wer das nicht aushält, baut in 16 statt 8 Wochen — und verliert sechs Wochen Lernzeit.

Build-Stack 2026 — was wirklich liefert

Bolt oder Lovable für die Frontend-Geschwindigkeit

Bolt und Lovable sind 2026 die schnellste Möglichkeit, von Idee zu funktionierender Web-App zu kommen. Beide generieren echten Code (React, Next.js), nicht nur No-Code-Bausteine. Erste lauffähige Version in unter einer Stunde. Iterationen in Minuten statt Tagen.

Was beide gut können: Frontend, einfache Backends, Datenbank-Anbindung, Auth. Was sie weniger gut können: komplexe Backend-Logik, Spezial-Integrationen, Skalierungs-Themen. Für ein MVP völlig ausreichend.

Bubble für No-Code-only-Cases

Bubble bleibt 2026 relevant für Cases, in denen kein klassischer Code gewünscht ist und visuelle Workflows ausreichen. Funktioniert besonders gut für interne Tools, einfache Marketplaces, schnelle Prototypen. Lock-in höher als bei Bolt — wer später skalieren will, muss meist neu bauen.

Stripe für Payment, Resend für E-Mail

Stripe ist Standard für Payment in B2B-MVPs. Setup in einem Tag, Subscription-Management out of the box, gute Developer-Experience. Resend (oder alternativ Postmark) ist Standard für transaktionale E-Mails. Beide haben kostenfreie Tier für die ersten Hunderte Transaktionen — perfekt für die MVP-Phase.

Hosting auf Vercel oder Netlify

Vercel oder Netlify für Hosting — kostenfrei in der MVP-Phase, automatisches Deployment aus Git, sehr gute Developer-Experience. Für deutsche Datenresidenz alternativ Hetzner Cloud, etwas mehr Setup-Aufwand.

Claude Code als KI-Assistent

Claude Code (oder vergleichbare Tools wie Cursor) als Bau-Assistent für die Stellen, an denen Bolt/Lovable an Grenzen stoßen — komplexere Backend-Logik, Daten-Migrationen, spezifische Integrationen. 17 Euro pro Monat im Pro-Plan, 100 Euro im Max-Plan. Macht den Unterschied zwischen „Bolt baut 70 Prozent" und „MVP läuft komplett".

Pre-Sales — der wichtigste Hebel

5 bis 10 zahlende Kunden vor Tag 1

Das beste MVP ist eines, für das vor Launch schon Geld geflossen ist. Pre-Sales heißt: In Woche 1 bis 4 mit potenziellen Kunden sprechen, das Wertversprechen erklären, einen Vorab-Vertrag abschließen mit Discount für die ersten Nutzer. „Sie zahlen 50 Prozent jetzt, bekommen das Produkt in acht Wochen, kriegen die ersten zwölf Monate zum halben Preis."

Das ist hart — viele Gründer trauen sich das nicht. Aber es liefert vier Dinge auf einmal: Validierung der Zahlungsbereitschaft, Cash für die Bauphase, Commitment der ersten Kunden, klares Briefing für das Produkt (denn die Kunden, die zahlen, sagen sehr genau, was sie wollen).

„Pilotkunden" mit echtem Geld

Eine Variante: Pilotkunden statt Vollkunden. Diese zahlen einen reduzierten Preis (etwa 30 bis 50 Prozent) und bekommen im Gegenzug intensiven Support und das Recht, die Roadmap mitzubestimmen. Das ist ein faires Trade-off — und liefert genau die Detail-Insights, die in Phase 1 für das Produkt entscheidend sind.

Was nicht funktioniert

Was nicht funktioniert: kostenfreie „Beta-Nutzer". Wer das Produkt umsonst nutzen darf, gibt selten ehrliches Feedback — und ist nicht committet, das Produkt wirklich zu nutzen. Kostenfreie Nutzer sind in der MVP-Phase Lärm, kein Signal.

Ein MVP, für das in Woche 8 niemand bezahlen will, war kein MVP. Es war eine teure Übung im Selbstbestätigen.

Was häufig schiefgeht

Scope-Aufblähung in Woche 3 bis 5

Der Klassiker: In Woche 3 kommen aus den ersten Tests Wünsche. „Können wir nicht auch X einbauen?" In Woche 4 kommen weitere Wünsche. In Woche 5 ist die Liste dreimal so lang wie in Woche 1, und der Termin in Woche 8 ist nicht mehr haltbar. Gegenmittel: V2-Liste konsequent führen, nichts in V1 dazu nehmen, was nicht im ursprünglichen Scope-Dokument stand.

Bau ohne Pre-Sales

Wer in Woche 8 mit „ein bisschen Marketing" launchen will, ohne vorab zahlende Kunden zu haben, verbringt nach dem Launch weitere drei bis sechs Monate damit, die ersten Kunden zu gewinnen. In dieser Zeit ist die Cash-Burn hoch, das Produkt verändert sich kaum, die Lernzyklen sind lang. Pre-Sales kürzt diese Phase massiv ab.

Falscher Stack

Wer in Woche 1 anfängt, eine eigene Microservices-Architektur mit Kubernetes aufzubauen, hat in Woche 8 noch keine Login-Page. Der falsche Stack ist eine der häufigsten Ursachen für gescheiterte MVPs. Faustregel: in der MVP-Phase die schnellsten verfügbaren Tools nutzen, auch wenn sie später ersetzt werden müssen. Time-to-Market schlägt Architektur-Reinheit.

Was nach dem MVP kommt

Wenn das MVP läuft und die ersten zahlenden Kunden glücklich sind, beginnt die nächste Phase: Skalierung des Produkts und des Vertriebs. Das ist eine andere Disziplin — mit anderen Werkzeugen und anderen Risiken. In der Skalierungs-Phase wird nicht mehr in 8-Wochen-Zyklen gedacht, sondern in Quartals-Roadmaps. Das Produkt wird stabiler, der Vertrieb professionalisiert sich, das Team wächst.

Aber bevor diese Phase beginnt, muss das MVP wirklich stehen. Mehr zur größeren Logik der frühen Startup-Phase im Artikel KI-First-Stack für Gründer 2026 und zu der Frage, wie die richtige Pre-Seed-Finanzierung aussieht, in Pre-Seed Finanzierung — Family, Angels, Operator-Capital.