Wie lange dauert es, ein SaaS zu bauen?

Warum es keine pauschale Antwort gibt

Wie lange dauert es, ein SaaS zu bauen? Diese Frage hören wir fast in jedem ersten Gespräch. Sie ist genauso sinnvoll wie die Frage, wie lange es dauert, ein Haus zu bauen. Ein Gartenhaus steht an einem Wochenende. Ein Mehrfamilienhaus beschäftigt ein Team über Monate. Das Wort Haus passt auf beides und sagt fast nichts über die Dauer. Bei Software ist es nicht anders. Die Dauer ist keine Eigenschaft der Technologie, sondern eine Folge des Scope.

Scope ist die Summe dessen, was das Produkt können muss: welche Funktionen, für wie viele Nutzerrollen, an welche fremden Systeme angebunden, mit welchen Anforderungen an Sicherheit, Verfügbarkeit und Datenschutz. Zwei Teams bauen vermeintlich dasselbe SaaS, und das eine braucht sechs Wochen, das andere sechs Monate. Der Unterschied liegt nicht im Können, sondern darin, dass das eine Team einen scharf geschnittenen ersten Ausschnitt baut, während das andere von Anfang an alles abdecken will.

Eine Zahl ohne Kontext taugt deshalb nichts. Was dir wirklich hilft, ist ein Modell, mit dem du die Dauer selbst aus deinem Vorhaben ableitest. Genau dieses Modell baust du dir in diesem Artikel Schritt für Schritt zusammen.

In Phasen denken statt in einer Zahl

Ein SaaS entsteht nicht in einem Block. Es entsteht in Phasen, die unterschiedlich viel Zeit kosten und sich teils überlappen. Wer die Dauer schätzen will, schätzt nicht das Ganze auf einmal, sondern jede Phase für sich.

Am Anfang steht die Klärung: Was löst das Produkt für wen, welcher Ausschnitt kommt zuerst, wie sieht der zentrale Ablauf aus. Diese Phase wird gern unterschätzt, weil dabei noch kein Code entsteht. Sie entscheidet aber über alles Weitere. Eine Woche saubere Klärung spart dir später Wochen an Umbau.

Dann kommt die Grundausstattung, die fast jedes SaaS braucht. Nutzer registrieren und melden sich an, es gibt Rollen und Rechte, Daten liegen sicher gespeichert, und das Ganze läuft auf einer Infrastruktur, die du betreiben und aktualisieren kannst. Dieser Teil sieht bei den meisten Produkten erstaunlich ähnlich aus, und gerade deshalb lässt er sich gut abschätzen.

Die Kernfunktion ist das, was dein Produkt von anderen unterscheidet. Hier steckt die eigentliche Unsicherheit, weil dieser Teil neu ist und sich nicht aus vergangener Erfahrung ablesen lässt. Zum Schluss folgen Härtung und Betrieb: Testen unter Last, Fehler abfangen, Monitoring, der erste echte Nutzer. Diese Phase verschwindet in optimistischen Plänen gern komplett, obwohl sie darüber entscheidet, ob der Start gelingt oder im Frust endet.

Betrachtest du diese vier Phasen einzeln, fällt dir schnell etwas auf: Die Grundausstattung ist gut planbar, die Kernfunktion trägt das Risiko, und die Härtung wird fast immer vergessen.

Drei Faktoren, die die Dauer wirklich treiben

Drei Dinge bestimmen den grössten Teil der Zeit. Verstehst du sie, kannst du jede Schätzung selbst auf Plausibilität prüfen.

Der erste ist der Funktionsumfang, also die schiere Zahl der Dinge, die das Produkt können muss. Jede Funktion bringt nicht nur ihren sichtbaren Teil mit, sondern auch Sonderfälle, Fehlerbehandlung und Wechselwirkungen mit allem anderen. Zehn Funktionen sind weit mehr als doppelt so aufwendig wie fünf, weil sie sich gegenseitig in die Quere kommen. Disziplin beim Schneiden des ersten Ausschnitts zahlt sich nirgends so stark aus wie hier.

Der zweite sind Integrationen, Verbindungen zu Systemen, die du nicht kontrollierst: ein Zahlungsanbieter, ein CRM, ein ERP, die Schnittstelle eines Geschäftspartners. Jede davon hat ihre eigene Logik, ihre eigenen Fehlerzustände und ihre eigene Dokumentation, die nicht immer stimmt. Eine einzige Anbindung an ein altes, schlecht dokumentiertes System kann dich länger beschäftigen als drei eigene Funktionen zusammen. Wir haben Schätzungen öfter an Integrationen scheitern sehen als an irgendetwas sonst, weil die Gegenstelle sich nicht an deinen Plan hält.

Der dritte ist die Tiefe von Anmeldung und Abrechnung. Nutzer melden sich an, das klingt simpel, ist es aber nur im einfachsten Fall. E-Mail und Passwort sind Standardarbeit. Sobald Anmeldung über bestehende Firmenkonten, Teams mit fein abgestuften Rechten oder mehrere getrennte Mandanten dazukommen, wächst der Aufwand sprunghaft. Bei der Abrechnung dasselbe: ein fester Preis ist schnell gebaut, doch gestaffelte Tarife mit nutzungsabhängiger Abrechnung, Gutschriften und Rechnungen sind ein eigenes kleines Produkt. Wie tief diese Mechanik reichen muss, treibt die Dauer oft stärker als die Kernfunktion selbst. Wie sich dieselben Treiber auf das Budget niederschlagen, liest du in Was kostet ein MVP.

MVP in Wochen, volles Produkt in Monaten

Mit diesem Verständnis löst sich der scheinbare Widerspruch auf, dass die einen von Wochen und die anderen von Monaten reden. Beide können recht haben, weil sie über verschiedene Dinge sprechen.

Ein MVP ist die kleinste Version, mit der echte Nutzer den Kernnutzen erleben. Konsequent geschnitten ist er eine Sache von Wochen. Konsequent geschnitten heisst: eine Nutzerrolle statt fünf, ein zentraler Ablauf statt zwanzig, eine einfache Anmeldung, ein simples Preismodell und nur die Integrationen, ohne die gar nichts läuft. So ein MVP ist nicht halbfertig, er ist absichtlich klein. Sein Zweck ist Lernen: Wollen Menschen dieses Problem gelöst haben, und zwar auf diesem Weg. Welche Wege dorthin führen, beschreiben wir in Beste Wege, ein MVP zu bauen.

Ein volles Produkt ist etwas anderes. Es bedient mehrere Nutzergruppen, deckt Sonderfälle ab, ist gegen Missbrauch und Ausfall gehärtet, läuft stabil im Betrieb und fügt sich in die Systeme ein, die deine Kunden ohnehin nutzen. Dieser Reifegrad dauert Monate, nicht weil das Bauen plötzlich langsamer wird, sondern weil der Scope um ein Vielfaches grösser ist. Zwischen MVP und vollem Produkt liegt kein anderer Code, sondern eine andere Menge Code.

Wichtig: Die beiden sind keine Gegensätze, sondern Stationen auf demselben Weg. Ein gut gebauter MVP ist das Fundament des späteren Produkts, vorausgesetzt, er ist auf Wachstum ausgelegt und nicht als Wegwerf-Prototyp gedacht. Wer den MVP in eine Sackgasse baut, zahlt den Umbau später doppelt. Welche Fehler dabei immer wieder passieren, zeigen wir in Warum SaaS-Projekte scheitern.

Wie du die Dauer für dein Vorhaben selbst abschätzt

Du musst kein Entwickler sein, um eine brauchbare Schätzung herzuleiten. Du brauchst nur eine Methode, die die drei Treiber von oben nutzt.

Fang beim zentralen Ablauf an. Schreib in einfachen Sätzen auf, was ein Nutzer Schritt für Schritt tut, um den Kernnutzen zu erleben, vom ersten Anmelden bis zum Ergebnis. Passt das in wenige Schritte, hast du einen kleinen Scope. Schiebst du ständig ein und ausserdem oder ausser wenn dazwischen, wächst er, und mit ihm die Dauer.

Geh dann die Treiber einzeln durch. Zähl die wirklich nötigen Funktionen, nicht die wünschenswerten. Liste jede externe Verbindung auf und frag bei jeder: Stiftet das Produkt ohne sie schon Nutzen? Kläre, wie tief Anmeldung und Abrechnung am Anfang sein müssen. Die entscheidende Frage bleibt jedes Mal dieselbe: Braucht die erste Version das, oder kann es warten? Jedes kann warten verschiebt Aufwand nach hinten und verkürzt die Zeit bis zum ersten echten Nutzer.

Trenne danach sauber zwischen Bekanntem und Unbekanntem. Die Grundausstattung ist bekanntes Terrain und gut schätzbar. Die Kernfunktion ist meist neu und damit unsicher. Für den unsicheren Teil sagt dir eine Spanne mehr als eine einzelne Zahl, und ein bewusster Puffer ist keine Schwäche, sondern ein Zeichen, dass du verstanden hast, wo die Risiken liegen. Nennt dir jemand für den unsicheren Teil eine punktgenaue Zahl ohne Spanne, sei vorsichtig.

Plan zuletzt die gern vergessene Phase nach dem ersten Lauffähig ein: Testen unter realen Bedingungen, Fehler abfangen, Betrieb einrichten. Als Faustregel gilt, dass der Weg vom läuft bei uns zum läuft beim Kunden selten zu lang geplant ist, fast immer aber zu kurz.

Gehst du diese vier Schritte durch, bekommst du keine magische Zahl. Du bekommst etwas Besseres: ein Verständnis davon, woraus sich die Dauer zusammensetzt und an welchen Stellen du sie durch klare Entscheidungen verkürzt.

Wann eine schnelle Zahl trotzdem in Ordnung ist

Manchmal willst du keine Methode, sondern nur einen Daumenwert, um zu entscheiden, ob sich das Vorhaben überhaupt rechnet. Das ist legitim. Eine grobe Spanne früh im Prozess hilft dir, eine Idee zu verwerfen oder weiterzuverfolgen, bevor du Zeit in eine genaue Planung steckst. Du solltest nur wissen, was so eine Zahl ist und was nicht. Sie ist ein Filter, keine Zusage. Wer sie später als verbindlichen Liefertermin behandelt, baut Druck auf, der sich am Ende in Abkürzungen bei Tests und Betrieb entlädt, also genau dort, wo es teuer wird.

Und es gibt Fälle, in denen die ganze Frage nach der Bauzeit am Thema vorbeigeht. Willst du nur prüfen, ob ein Markt da ist, brauchst du oft gar kein Produkt, sondern eine Landingpage, ein manuell bedientes Angebot oder ein bestehendes No-Code-Werkzeug. Das steht in Tagen statt Wochen. Erst wenn klar ist, dass die Nachfrage trägt, lohnt sich die Bauzeit für ein richtiges SaaS. Welcher Weg zu welcher Situation passt, vergleichen wir in Selbst bauen, Agentur, No-Code oder Produktstudio.

Warum Betrieb die Schätzung erst belastbar macht

Viele Schätzungen enden mit dem Tag, an dem das Produkt fertig ist. Das ist der eigentliche Denkfehler, denn ein SaaS wird nie fertig. Es läuft, es hat Nutzer, es braucht Aktualisierungen, es stösst auf Fälle, die niemand vorhergesehen hat. Wer nur baut und dann weiterzieht, blendet diesen Teil der Realität aus, und gerade dieser Teil entscheidet, ob das Produkt nach dem Start auch trägt.

Wir bei Wertstifter schätzen anders, weil wir nicht nur bauen, sondern eigene Produkte selbst betreiben. Reazon, das CMS, in dem dieser Artikel liegt, und Wortfreunde, unser Sprachlernprodukt, laufen Tag für Tag mit echten Nutzern. Das verändert die Schätzung: Wir wissen aus eigener Erfahrung, dass die Wochen nach dem Start kein Anhang sind, sondern fester Teil der Dauer. Eine reine Bau-Agentur hat das oft nicht im Blick, weil ihr Auftrag mit der Übergabe endet.

Die nützlichste Antwort auf die Ausgangsfrage ist deshalb keine Zahl, sondern eine Haltung. Schneide den ersten Ausschnitt klein genug, dass er in Wochen echten Nutzern dient. Plane die Reife zum vollen Produkt in Monaten. Und rechne den Betrieb von Anfang an mit ein. Denkst du diese drei Dinge zusammen, ist die Dauer keine Wundertüte mehr, sondern eine Folge von Entscheidungen, die du selbst in der Hand hältst. Wie wir das konkret umsetzen, zeigen wir auf unserer Seite zur SaaS-Produktentwicklung.