SaaS MVP in 90 Tagen - Vom Anforderungsdokument zum Launch

"In drei Monaten launchen" ist eines der häufigsten Versprechen, das Gründer ihren Investoren oder sich selbst geben - und eines der häufigsten Versprechen, das nicht eingehalten wird. Nicht, weil 90 Tage unrealistisch sind, sondern weil die Zeit an der falschen Stelle verloren geht.

Wo die Zeit wirklich verloren geht

Die verbreitete Annahme ist, dass Entwicklung der zeitaufwendigste Teil eines MVPs ist. Tatsächlich ist es fast immer die Phase davor: unklare Anforderungen, die während der Entwicklung mehrfach nachverhandelt werden, weil sie beim Start nicht zu Ende gedacht waren. Ein typisches Beispiel: Ein Buchungstool soll "Zahlungen abwickeln können" - aber erst in Woche 6 stellt sich heraus, dass damit auch Teilzahlungen, Stornos und drei verschiedene Zahlungsanbieter gemeint waren. Jede dieser Nachverhandlungen kostet nicht nur die Zeit für die Änderung selbst, sondern auch Wartezeit, Abstimmungsschleifen und oft ein neues Teilangebot.

Ein realistischer 90-Tage-Plan

Woche 1-2: Anforderungen präzisieren

Bevor ein einziger Entwickler involviert wird: Welche Kernfunktion löst das eigentliche Problem deiner Zielgruppe? Was ist für den Launch nicht notwendig? Diese Abgrenzung ist die wichtigste Entscheidung im gesamten Projekt - sie bestimmt, wie viel von den 90 Tagen tatsächlich für Entwicklung übrig bleibt.

Konkret solltest du in diesen zwei Wochen:

jede geplante Funktion einzeln aufschreiben und mit "Muss für Launch", "Kann später" oder "Nice-to-have" markieren
pro Funktion eine konkrete Nutzerhandlung beschreiben, nicht nur ein Stichwort ("Nutzer exportiert seine Rechnungen als PDF", nicht "Export-Funktion")
Randbedingungen festhalten: welche Drittsysteme müssen angebunden werden, welche gesetzlichen Vorgaben gelten, welches Budget steht fest

Ein KI-gestützter Anforderungs-Check deckt in wenigen Minuten auf, wo dein Konzept noch Lücken oder Widersprüche hat - bevor diese Lücken im Angebot eines Entwicklungspartners als Risikoaufschlag auftauchen.

Woche 3: Festpreisangebot einholen

Mit einem präzisen Anforderungsdokument lässt sich ein verbindliches Festpreisangebot innerhalb weniger Tage erstellen, statt sich über Wochen mit mehreren Anbietern in unscharfen Abstimmungsrunden zu verlieren. Ein belastbares Angebot in dieser Phase enthält:

eine Aufschlüsselung nach Funktionsblöcken, nicht nur eine Gesamtsumme
einen klaren Änderungsprozess für alles, was nicht im Lastenheft steht
einen Zeitplan mit benannten Meilensteinen, nicht nur ein Enddatum

Wenn ein Anbieter in dieser Phase noch grundlegende Rückfragen zum Umfang stellt, ist das ein Warnsignal - es deutet darauf hin, dass das Anforderungsdokument aus Woche 1-2 noch nicht präzise genug war.

Woche 4-10: Entwicklung in Sprints mit klaren Meilensteinen

Sieben Wochen reine Umsetzungszeit reichen für ein fokussiertes MVP - vorausgesetzt, der Scope wurde in Woche 1-2 wirklich eng genug gefasst. In der Praxis bewährt sich eine Aufteilung in wöchentliche Sprints mit einem festen Rhythmus:

Montags: kurzer Abstimmungspunkt zum Stand der letzten Woche
Freitags: ein klickbarer Zwischenstand, den du selbst testen kannst

Diese wöchentlichen Zwischenstände sorgen dafür, dass Abweichungen früh sichtbar werden, statt erst kurz vor dem Launch. Plane außerdem bewusst eine Pufferwoche innerhalb dieses Zeitraums ein - nicht, weil etwas schiefgehen muss, sondern weil bei praktisch jedem Projekt mindestens eine Integration (Zahlungsanbieter, E-Mail-Versand, Login-Anbieter) mehr Abstimmung braucht als geplant.

Woche 11-12: Testing, Feinschliff, Launch-Vorbereitung

Die letzten zwei Wochen gehören Tests mit echten (oder echten Test-)Nutzern, kleineren Korrekturen und der eigentlichen Launch-Vorbereitung - nicht der hektischen Fertigstellung fehlender Kernfunktionen. Zu einer sauberen Launch-Vorbereitung gehören:

ein Test mit 5-10 externen Personen aus der Zielgruppe, nicht nur dem eigenen Team
ein kurzer Lasttest, wenn zum Launch-Zeitpunkt mit einem Ansturm zu rechnen ist (z. B. durch eine Presseankündigung)
rechtliche Pflichtseiten (Impressum, Datenschutzerklärung, AGB) und ein DSGVO-konformer Umgang mit Nutzerdaten
ein Rollback-Plan, falls nach dem Launch ein kritischer Fehler auftritt

Typische Stolperfallen im 90-Tage-Zeitplan

Auch bei guter Planung gibt es wiederkehrende Muster, die den Zeitplan gefährden:

Drittanbieter-Integrationen werden unterschätzt. Zahlungsanbieter, E-Mail-Versand oder Login-Systeme bringen eigene Freigabeprozesse und Wartezeiten mit, die außerhalb deiner Kontrolle liegen. Starte diese Anmeldungen parallel zur Entwicklung, nicht erst kurz vor dem Launch.
Feedback aus der Beta-Phase wird nicht eingeplant. Wenn du erst in Woche 12 zum ersten Mal echte Nutzer testen lässt, bleibt keine Zeit mehr, um auf deren Feedback zu reagieren.
Scope-Änderungen werden "schnell mal eben" reingenommen. Jede zusätzliche Anforderung nach Projektstart sollte formal bewertet werden - auch wenn sie klein wirkt.

Der größte Hebel: Scope-Disziplin

MVP heißt "Minimum Viable Product" - nicht "möglichst viele Features in möglichst kurzer Zeit". Jede zusätzliche Funktion, die in der Konzeptphase nicht konsequent rausgekürzt wird, verlängert die Entwicklungszeit überproportional, weil sie zusätzliche Sonderfälle, Tests und Integrationen nach sich zieht. Eine gute Faustregel: Wenn eine Funktion in der ersten Version fehlt, aber niemand aus deiner Zielgruppe sie in den ersten vier Wochen nach Launch aktiv vermisst, war die Entscheidung, sie rauszulassen, richtig.

Was, wenn 90 Tage nicht reichen?

Manche Projekte sind auch mit engem Scope in 90 Tagen nicht realistisch umsetzbar - etwa, wenn mehrere komplexe Drittsystem-Integrationen zwingend zum Launch nötig sind. In diesem Fall ist ein gestufter Launch oft die bessere Alternative zu einem verschobenen Termin: eine private Beta mit wenigen Nutzern zum ursprünglichen Termin, der öffentliche Launch mit vollem Funktionsumfang einige Wochen später. So hältst du den Termin nach außen ein, ohne den Scope nachträglich unter Zeitdruck zu erweitern.

Was du für den Zeitplan selbst beisteuern musst

Ein 90-Tage-Zeitplan ist keine Einbahnstraße, bei der du nur wartest, bis der Entwicklungspartner liefert. Damit die Wochen 4-10 tatsächlich in Entwicklung fließen und nicht in Wartezeit auf dich, solltest du von Anfang an einplanen:

Eine feste Ansprechperson auf deiner Seite, die innerhalb von ein bis zwei Werktagen auf Rückfragen antworten kann. Jede Rückfrage, die eine Woche unbeantwortet bleibt, verschiebt den Zeitplan real um diese Woche.
Zugänge und Zugangsdaten vorbereitet, bevor sie gebraucht werden - etwa für Zahlungsanbieter-Konten, Domain-Verwaltung oder bestehende Systeme, die angebunden werden müssen.
Testinhalte und Beispieldaten, damit die Entwicklung nicht mit Platzhaltertexten arbeitet, die später ohnehin ausgetauscht werden müssen.

Diese drei Punkte kosten dich selbst kaum Zeit, verhindern aber die häufigste Ursache für stille Verzögerungen: Wartezeit auf Informationen, die eigentlich längst hätten vorliegen können.

Fazit

90 Tage für ein SaaS-MVP sind realistisch - aber nur, wenn die ersten zwei Wochen konsequent in die Anforderungsklärung investiert werden, statt direkt mit der Entwicklung zu starten. Diese Investition zahlt sich in Form eines belastbaren Festpreises und eines Launch-Termins aus, der tatsächlich hält.

Häufig gestellte Fragen

Ist ein SaaS-MVP wirklich in 90 Tagen realistisch?

Ja, für einen eng gefassten Funktionsumfang ist das machbar. Die Voraussetzung ist, dass die ersten zwei Wochen konsequent in die Anforderungsklärung investiert werden. Projekte, die stattdessen direkt mit der Entwicklung starten, verlieren die Zeit später durch Nachverhandlungen wieder.

Was passiert, wenn während der Entwicklung neue Anforderungen auftauchen?

Jede neue Anforderung sollte formal bewertet werden, statt "schnell mal eben" reinzurutschen. Ein guter Festpreisvertrag regelt einen klaren Änderungsprozess dafür, damit Zusatzwünsche nicht unkontrolliert den Zeitplan sprengen.

Wie viel Zeit sollte ich für die Anforderungsklärung vor der Entwicklung einplanen?

Etwa zwei Wochen zu Beginn des Projekts sind ein guter Richtwert. In dieser Zeit werden Funktionen priorisiert, konkrete Nutzerhandlungen beschrieben und Randbedingungen wie Drittsystem-Integrationen und rechtliche Vorgaben festgehalten.

Was tun, wenn der Funktionsumfang nicht in 90 Tagen passt?

Ein gestufter Launch ist oft besser als eine Terminverschiebung: eine private Beta mit wenigen Nutzern zum ursprünglichen Termin, der öffentliche Launch mit vollem Funktionsumfang einige Wochen später.