[Inhaltsverzeichnis]Inhaltsverzeichnis anzeigen
Ein MVP in 8 Wochen ist realistisch — genau dann und nur dann, wenn drei Bedingungen erfüllt sind: Das Geschäftsproblem ist eindeutig definiert, echte Nutzer sind bereit, das Produkt in Woche 4 zu testen, und der Scope lässt sich auf einen zentralen Flow reduzieren. DailyHair hat alle drei erfüllt: (1) Eventmanager verloren 6 Stunden pro Woche mit der Koordination von 30+ Medienpatronen, (2) drei Pilotkonferenzen warteten zwischen Woche 4 und 7, (3) ein Flow — Briefing-Freigabe per Magic Link. Außerhalb dieser Bedingungen ist „MVP in 8 Wochen” Marketing, keine Engineering-Aussage. Bezahlt wird mit technischen Schulden, die niemand in der Bilanz abschreibt — die aber im dritten Monat nach dem Launch sichtbar werden.
Dieser Text steht auf zwei Perspektiven gleichzeitig. Erstens: Wir haben als Venture Builder 12 eigene Produkte gestartet und wissen, was in 8 Wochen passt, wenn es unser Geld ist. Zweitens: In Individualsoftware-Projekten liefern wir ebenfalls MVPs und wissen, was passt, wenn der Kunde den Scope bezahlt. Diese zwei Welten lehren unterschiedliche Dinge. Das folgende Framework ist deren Synthese.
Wann 8 Wochen realistisch sind
Vager Brief: „Baut uns eine Eventplattform.” Realer Brief: „Der Medienpartner gibt das Briefing in 3 Tagen frei, Event in 2 Wochen.” Das eine ist eine Feature-Liste, das andere ein Bottleneck mit tickender Uhr. Das Problem wird auf der Ebene eines konkreten Schmerzes, einer konkreten Person und einer konkreten Metrik formuliert, die wir verschieben wollen. Wenn das Team nicht sagen kann, was nach dem Launch aufhört wehzutun — ist das kein MVP, sondern ein Prototyp ohne Publikum.
Zweite Bedingung: Zugang zu echten Nutzern in Woche 4. Keine hypothetischen Personas aus UX-Workshops, sondern konkrete Menschen mit Namen und Telefonnummern, die zugesagt haben, früh zu testen. Ein MVP ohne Nutzer in der Projektmitte testet die Annahmen des Teams, nicht den Markt. Bei Projekten, in denen der Kunde sagt „die Nutzer finden wir nach dem Launch”, verschiebt sich die Lieferzeit auf 12-16 Wochen — weil wir ohnehin eine zweite Version bauen müssen, bevor die erste irgendjemandem Wert liefert.
Dritte Bedingung: ein einziger primärer Flow. Der Nutzer kommt, macht eine Sache, geht mit Mehrwert. Alles andere ist Beiwerk — Admin-Ansichten, Einstellungen, Export, Benachrichtigungen. Enthält ein MVP zwei gleichgewichtige Flows (etwa „für Eventmanager und für Medienpatrone gleichzeitig”), ist es kein MVP — es sind zwei MVPs, die sich als eines tarnen. In 8 Wochen baut man einen Flow sehr gut oder zwei Flows mittelmäßig. Mittelmäßigkeit im MVP ist schlimmer als kein MVP, weil sie die Hypothese widerlegt, statt sie zu testen.
Wann 8 Wochen eine Red Flag sind
Der Kunde wollte SAP-Integration im MVP. Ich sagte Nein. Er fand jemanden, der Ja sagte. 16 Wochen später rief er bei uns an. Das Marktfenster war zu. Jede Enterprise-Integration — SAP PI, Salesforce, NetSuite, lokale ERP-Systeme, HL7/FHIR im Gesundheitswesen, SWIFT im Banking — ist ein eigenes Projekt, kein Sprint-Ticket. Die SAP-Integration selbst (Abstimmung mit der internen IT des Kunden, Testumgebungen, Mappings) dauert 6-10 Wochen, ohne eine Zeile Applikations-Code. Steht und fällt ein MVP an einer einzelnen Enterprise-Integration, ist es kein MVP — es ist ein Integrationsprojekt mit UI gratis obendrauf.
Ein MVP für 50 Personas in 3 Vertikalen in 3 Ländern gleichzeitig. Das ist Waterfall, das so tut, als wäre es Agile. Wir haben es auf eine Vertikale zurückgesetzt. Im Brief steht: „Die Plattform muss sowohl Meetups bis 100 Personen, kameralen Branchenkonferenzen als auch Kulturfestivals für 50.000 Teilnehmer bedienen, mit Expansion in deutsche, ukrainische und spanische Märkte im Hinterkopf.” Jedes Segment hat ein eigenes Patronatsmodell, eigene Prozesse, eigene regulatorische Anforderungen. Ein MVP für alle Segmente erzeugt eine Architektur, die zu keinem passt. Die richtige Entscheidung: ein Segment im MVP, der Rest als v2. Die Geschäftsarchitektur eines MVP sollte auf Erweiterbarkeit ausgelegt sein, nicht auf alle Fälle gleichzeitig.
Drittes Anti-Pattern: kein Mechanismus zum Testen mit Nutzern. „Wir machen Tests nach dem Launch” ist kein Testplan — das ist der Verzicht auf Tests. Ohne Feedback-Schleife in Woche 4 wird das MVP zu einem 8-Wochen-Prototyp, der erst nach dem Deployment zu lernen beginnt. Es ist der teuerste Zeitpunkt, um zu entdecken, dass das Problem falsch gestellt war — denn das Budget ist bereits ausgegeben.
Viertes Anti-Pattern: Compliance-schwere Domänen mit auditpflichtigen Workflows. Banking (BaFin, PSD2, SOX), Gesundheitswesen (DSGVO in klinischen Details, HL7/FHIR), öffentlicher Sektor (E-Akte, Onlinezugangsgesetz, KRITIS), Pharma (GxP). In diesen Domänen kosten allein die Audit-Schicht, Datenretention und Berechtigungen 4-6 Wochen Arbeit. Ein 8-Wochen-MVP in einer Compliance-schweren Domäne bedeutet entweder Compliance auslassen (inakzeptables Risiko) oder das Produkt auf eine Fassade reduzieren. Reale MVP-Dauer in solchen Domänen: 14-20 Wochen.
DoMoreSoft MVP Scoping Framework
Diese Matrix entstand aus der Beobachtung realer Projekte. Score unter 15? Etwas bricht. 15-20? Eng, aber machbar. 20+? Grünes Licht. Wir bewerten ein Projekt in fünf Dimensionen auf einer Skala von 1-5. Das Framework ist pragmatisch — es ersetzt keinen Scoping-Workshop, aber es setzt das Niveau der Unterhaltung in den ersten 30 Minuten.
MVP Scope Checklist — was in 8 Wochen passt
Der konkrete Umfang, den wir in einem pragmatischen MVP bei einem Framework-Score von 20+ liefern:
- Authentifizierung und Nutzerregistrierung (E-Mail/Passwort, optional SSO)
- Ein primärer User-Flow end-to-end — vom Einstieg bis zum Wert (etwa Buchung, Bestellung, Antragstellung)
- Eine Admin-Ansicht mit grundlegendem CRUD auf den wichtigsten Entitäten
- Eine externe Integration (Zahlung, SMS, Karten, Transaktions-E-Mail — die Domäne entscheidet)
- Grundlegende Produktanalytik — wer, wann, was, wo abgebrochen
- Deployment auf Staging plus Produktion, CI/CD, Error-Monitoring (Sentry/GlitchTip)
- DSGVO-Minimum: Datenschutzerklärung, Konto-Export und -Löschung, Einwilligungen
- Technische Dokumentation, mit der ein anderes Team den Code ohne Rescue Mission übernimmt
Nicht weil wir nett sind. Alles jenseits dieser Liste hat einen Schwanz versteckter Komplexität. Multi-Tenant? Drei Wochen Architekturschuld. Offline-Modus? Separates Projekt. Vollständiges RBAC? V3, nicht v2. Fällt einer dieser Punkte aus dem Scope, um die 8 Wochen zu halten, hört es auf, ein MVP zu sein — es wird ein Prototyp. Ein Fundament, auf dem 18-24 Monate ohne Rewrite gebaut werden kann, hat ein Minimum — und das liegt oben.
Was nicht passt (und warum das kein Scheitern ist)
- Multi-Tenant mit voller Datenisolation. Im MVP reicht ein einzelner Tenant oder eine gemeinsame Datenbank mit tenant_id-Schlüssel. Volle Isolation (Schema pro Tenant, Datenbank pro Tenant) sind 3-5 Wochen Architekturarbeit — sinnvoll erst bei ersten Enterprise-Kunden.
- Offline-Modus und Synchronisation. Eine App, die offline funktioniert (PWA mit Offline-Queue, CRDTs, Konflikt-Lösung), ist ein separates Projekt. Im MVP akzeptieren wir die Anforderung einer konstanten Verbindung.
- Fortgeschrittene Rollen und Berechtigungen. Im MVP reichen 2-3 Rollen (User, Admin, optional Manager). RBAC mit Berechtigungsmatrix auf Feldebene, ABAC, Audit-Trail jeder Änderung — das ist v2 oder v3.
- Reporting-Dashboards und BI. CSV-Export plus 3-5 zentrale Kennzahlen reichen. Vollständiges Reporting mit Filtern, Kohorten und Custom Queries wird erst gebaut, wenn klar ist, welche Daten das Business-Team tatsächlich nutzt.
- Internationalisierung (i18n). Eine Sprache im MVP. Eine zweite Sprache kostet mindestens 2 Wochen Arbeit (String-Extraktion, Pluralisierung, Daten, Währungen, Tests) — nicht sinnvoll im MVP zu bezahlen, wenn es noch keine Nutzer aus dem zweiten Markt gibt.
Diese Punkte auf v2 zu verschieben ist pragmatische Geschäftsarchitektur, die nicht für Funktionalität bezahlt, die noch niemand braucht. Jeder kommt zum richtigen Zeitpunkt zurück, begründet durch ein konkretes Bedürfnis statt durch eine Vermutung. Die Entscheidung, was nach v2 wandert, ist Teil des Discovery-Prozesses — keine Sprint-Improvisation.
Wie wir diese 8 Wochen kennen — wir machen es selbst
Wir haben das MVP von DailyHair — eine Plattform zur Verwaltung von Medienpatronaten und Kommunikation rund um Branchenveranstaltungen — in 8 Wochen gebaut. Konkretes aus unserem Log:
- Woche 1: Wir waren zu 40% bereit und in Panik. Backlog stand nicht im Verhältnis zu den Arbeitstagen.
- Woche 3: Wir haben 30% der geplanten Features gestrichen. Multi-Channel-Notifications, Custom-Reports, Integration mit zwei CRMs — alles ging nach v2.
- Woche 6: Erste Konferenz produktiv, Pivot zweier Flows nach Feedback der Eventmanager. Magic Link hat das Passwort geschlagen.
- Woche 8: Shipped. Drei Piloten angebunden, primärer Flow stabil.
Das ist keine Anekdote darüber, wie clever wir sind. Es ist der Beweis, dass das Framework funktioniert, wenn man es rigoros anwendet — auf sich selbst und auf Kunden. Wir tun das seit 2016, schon mit 12 eigenen Produkten, und jedes hat uns gelehrt, was aus der „Nice to have”-Liste wirklich nice und was versteckte technische Schuld ist.
Cost Math: 8 Wochen vs. 16 Wochen
Rechnen wir den TCO zweier Wege für dasselbe Produkt:
| Position | MVP 8 Wo. | MVP 16 Wo. |
|---|---|---|
| Entwicklungsbudget | 30-50k EUR | 80-140k EUR |
| Zeit bis Marktfeedback | 8 Wo. | 16 Wo. |
| Kosten eines Lernzyklus | niedrig | hoch |
| Risiko, das Falsche zu bauen | durch Scope begrenzt | hoch (mehr Annahmen, mehr Fehler) |
| Technische Schulden | kontrolliert bei Score 20+ | niedrig, wenn das Team nicht künstlich gehetzt hat |
Die Mathematik sieht eindeutig aus, aber es gibt eine Bedingung, die sie umdreht. Ein schlechtes MVP in 8 Wochen ist teurer als ein gutes MVP in 12 Wochen. Die Kosten, das Falsche zu bauen, sind nicht nur das Projektbudget, sondern auch Opportunitätskosten (Teamzeit), Glaubwürdigkeitskosten (die ersten Nutzer, die ein schlechtes Produkt testen, kommen nicht zurück) und die Kosten eines Refactors für eine v2, die das reale Problem endlich adressiert. In Summe können sie das Budget eines 16-Wochen-MVP übersteigen. Nur sind sie über die Zeit verteilt und in einem einzelnen Bericht weniger sichtbar.
Tempo ist nicht das Ziel. Das Ziel sind früh validierte Annahmen. Acht Wochen haben dann Sinn, wenn sie die Zeit bis zum Lernen verkürzen — nicht die Zeit bis zu „wir haben etwas, das aussieht wie ein Produkt”.
Red Flags auf Kundenseite, nicht nur beim Anbieter
Die meisten MVP-Artikel konzentrieren sich darauf, was der Anbieter gut machen muss. In der Praxis entgleisen Projekte auch aus Gründen auf Kundenseite — und Ehrlichkeit verlangt, sie beim Namen zu nennen. Drei, die ein 8-Wochen-MVP zu 16 Wochen machen, unabhängig von der Teamqualität:
Erstens: Scope-Änderung in jedem Sprint. Ein Kunde, der alle zwei Wochen neue Funktionen hinzufügt („ist eine Kleinigkeit, quetscht das noch rein”), garantiert Verzug. Jede Scope-Änderung ist eine Entscheidung: Fallen wir aus den 8 Wochen, oder fliegt etwas anderes aus dem Scope? Beides geht nicht. Ein reifer Kunde versteht, dass ein Scope-Freeze nach Woche 2 die Vorbedingung für pünktliche Lieferung ist.
Zweitens: kein Zugang zu Endnutzern. Ein Kunde, der sagt „die Nutzer stellen wir”, aber in Woche 3 noch keinen ersten Piloten gebucht hat, hat die Lernschleife abgeschaltet. Ab Woche 4 programmiert das Team blind — selbst bei korrekter Architektur werden Produktentscheidungen zu Vermutungen. Der Moment, das Projekt zu stoppen und einen Reset zu machen.
Drittens: Der Entscheider steht außerhalb des Projekts. Der Kunde delegiert das MVP an einen mittleren Manager ohne Befugnis für Scope-Entscheidungen. Jede relevante Entscheidung landet auf dem Schreibtisch des CEO, der einmal pro Woche antwortet — meist mit einer Scope-Änderung. Vorbedingung für ein 8-Wochen-MVP: ein Entscheider mit echter Befugnis, verfügbar im 48-Stunden-Rhythmus.
Prüfen, ob Ihr MVP in 8 Wochen passt?
Nutzen Sie das Framework oben — bewerten Sie die fünf Dimensionen auf einer Skala von 1-5, summieren Sie und sehen Sie, wo Sie landen. Score 20+: starten, die Bedingungen sind erfüllt. Score 15-19: reden wir über 10-12 Wochen oder einen Scope-Trim. Score unter 15: Sie brauchen einen Discovery-Workshop, kein MVP.
Schicken Sie Ihre Selbstbewertung an office@domoresoft.com. Sind Sie an der Grenze (17-20 Punkte), zeigt ein 30-minütiges Gespräch mit einem Architekten, was im MVP bleibt, was nach v2 wandert — und was es wirklich kostet. Für den Kontext, wie Sie den Partner bewerten, der dieses MVP tatsächlich liefern soll, empfehlen wir unser Framework zur Auswahl eines Software Houses 2026. Wir verkaufen „MVP in 8 Wochen” nicht als Regalprodukt — wir verkaufen ein ehrliches Gespräch darüber, ob diese 8 Wochen in Ihrem Fall realistisch sind.