Die Frage nach der Dauer einer SaaS-Entwicklung braucht zuerst einen klaren Zielzustand. Ein validierbarer Produktkern, ein erster zahlender Mandant und eine ausgereifte Plattform mit Self-Service, Abrechnung und Betrieb sind unterschiedliche Meilensteine. Deshalb gibt es keine universelle Wochen- oder Monatszahl, die für jedes SaaS-Produkt belastbar wäre.
Den Zielzustand präzise benennen
Vor jeder Schätzung sollte feststehen, was am geplanten Meilenstein tatsächlich nutzbar sein muss. Reicht ein geführtes Pilotprojekt mit manuell angelegten Konten? Müssen Kunden sich selbst registrieren, einen Tarif wählen und bezahlen können? Werden mehrere Organisationen, Rollen und getrennte Datenräume benötigt? Muss das Produkt bereits Support-, Datenschutz- und Verfügbarkeitsanforderungen eines Unternehmenskunden erfüllen?
Diese Fragen bestimmen nicht nur die Menge der Funktionen. Sie beeinflussen Architektur, Testtiefe und Betriebsmodell. Ein sinnvoller Scope beschreibt deshalb durchgängige Nutzerabläufe und Qualitätsanforderungen, nicht bloß eine Liste von Screens.
Die Arbeit in vier Stränge zerlegen
Produkt und UX: Zielgruppe, Kernproblem, Onboarding, wiederkehrender Nutzen und Feedbackmechanik. Anwendungslogik: der fachliche Kern, Rollen, Zustände und Regeln. Plattformfähigkeiten: Mandantenfähigkeit, Authentifizierung, Abrechnung, Benachrichtigungen und Administration. Betrieb: Deployment, Monitoring, Backups, Supportwege, Datenschutz und Sicherheit.
Diese Stränge laufen teilweise parallel, besitzen aber Abhängigkeiten. Ein Rollenmodell beeinflusst Oberfläche, Datenmodell und Tests. Ein noch ungeklärtes Preismodell beeinflusst Tarife und Abrechnung. Eine externe Integration kann erst realistisch eingeplant werden, wenn Dokumentation, Zugang und Testumgebung vorliegen.
Szenarien statt Scheingenauigkeit
Eine belastbare Planung beschreibt mindestens drei Szenarien. Im fokussierten Szenario sind Kernprozess und Voraussetzungen geklärt. Im erwartbaren Szenario werden wahrscheinliche Klärungs- und Feedbackschleifen berücksichtigt. Im Risikoszenario werden konkrete Unsicherheiten sichtbar, etwa eine komplexe Migration oder eine noch nicht geprüfte Schnittstelle.
Für jedes Szenario sollten Scope, Annahmen, benötigte Mitwirkung und Ausschlüsse dokumentiert sein. So kann ein Team bewusst entscheiden, ob es den Umfang reduziert, eine Unsicherheit zuerst mit einem Prototyp untersucht oder eine Abhängigkeit vor dem Build klärt. Eine einzelne Datumszusage ohne diese Bedingungen ist kein belastbarer Plan.
Typische Faktoren, die die Kalenderdauer bestimmen
- Entscheidungsgeschwindigkeit: Sind fachlich verantwortliche Personen für Rückfragen und Abnahmen verfügbar?
- Mandanten- und Rechtemodell: Wie werden Organisationen, Teams, Rollen und Daten getrennt?
- Integrationen: Sind API-Zugänge, Sandbox, Datenmapping und Fehlerwege geklärt?
- Abrechnung: Welche Tarife, Testphasen, Rechnungen, Steuern und Kündigungsregeln sind nötig?
- Migration: Welche Bestandsdaten müssen bereinigt, übernommen und geprüft werden?
- Marktanforderungen: Welche Sicherheits-, Datenschutz- oder Beschaffungsnachweise erwarten die ersten Kunden?
Meilensteine entlang von Erkenntnissen planen
Statt „SaaS fertig“ sind gestufte Meilensteine sinnvoll: Problem und Ablauf validiert, technischer Kern durchgängig, interner Test, begrenzter Pilot, erster verantwortbarer Produktivbetrieb und anschließend Self-Service oder Skalierung. Nicht jedes Produkt benötigt alle Fähigkeiten im ersten Meilenstein. Die Reihenfolge sollte das größte Produkt- oder Technikrisiko früh adressieren.
Nach jedem Meilenstein wird neu priorisiert. Nutzungsdaten und Gespräche können zeigen, dass eine zunächst wichtig erscheinende Funktion wenig beiträgt, während ein fehlender Arbeitsschritt die Nutzung blockiert. Diese Lernschleifen sind kein Planungsfehler, sondern ein wesentlicher Teil der Produktentwicklung. Die Planung sollte dafür bewusst Spielraum und klare Entscheidungstermine enthalten.
Wann eine Aussage zur Dauer belastbar wird
Eine erste Bandbreite wird belastbarer, sobald Zielgruppe, Kernablauf, Qualitätsniveau, Plattformumfang und externe Abhängigkeiten dokumentiert sind. Nach einem technischen Durchstich oder dem ersten vollständig umgesetzten Ablauf lassen sich verbleibende Muster besser beurteilen. Trotzdem bleiben Änderungen am Produktziel oder neue Integrationen echte Scope-Änderungen und nicht bloß Schätzfehler.
Die hilfreiche Frage lautet daher: „Welchen SaaS-Meilenstein können wir mit dem aktuellen Wissen verantwortbar planen, und welche Unsicherheit prüfen wir zuerst?“ Unterstützung bei Scope, Architektur und stufenweiser Umsetzung finden Sie unter SaaS entwickeln lassen; weitere Grundlagen stehen im SaaS-Ratgeber.