Warum SaaS-Projekte scheitern

Warum SaaS-Projekte scheitern, und woran man es erkennt

Wenn von gescheiterten SaaS-Projekten die Rede ist, denken die meisten an den grossen Knall. Das Geld ist weg, die Firma macht zu. In der Praxis sieht Scheitern fast immer leiser aus, und genau deshalb merkt man es zu spät.

Ein Produkt kann technisch sauber funktionieren, und trotzdem benutzt es niemand. Es kann Nutzer haben und kein Geld verdienen. Es kann laufen und im Betrieb so teuer sein, dass sich die Rechnung nie schliesst. Am häufigsten ist die unauffälligste Variante: Das SaaS startet mit Schwung und stirbt danach still, weil niemand es pflegt. Es ist online, aber es bewegt sich nichts mehr.

Das Gute ist, dass diese Gründe sich wiederholen. Wer sie kennt, umgeht die meisten. Hier sind die fünf, die uns in der Arbeit am häufigsten begegnen.

Am echten Bedarf vorbei gebaut

Der häufigste Grund hat mit Technik nichts zu tun. Ein Team verliebt sich in eine Idee und baut sie monatelang aus, ohne sie je einem echten Nutzer in die Hand zu geben. Jede Annahme über den Markt wandert ungeprüft in den Code. Zum Launch trifft das Produkt dann auf die Realität, und die wollte etwas anderes.

Solange du nur mit dir selbst, deinem Team und wohlwollenden Bekannten sprichst, klingt jede Idee gut. Das ist die Falle. Menschen aus der echten Zielgruppe verhalten sich anders, als alle vorhergesagt haben, und sie tun das zuverlässig.

Die Antwort darauf ist, früh und klein zu testen statt gross und spät. Bau die kleinste Version, mit der sich deine eine zentrale Annahme prüfen lässt, und gib sie echten Nutzern. Erst wenn diese Annahme hält, lohnt sich der Ausbau. Wie du den Umfang dafür schneidest und was er kostet, steht in Was kostet ein MVP.

Der Scope wächst schneller als das Wissen

Das zweite Muster schleicht sich ein. Das Produkt soll nur noch diese eine Funktion bekommen, dann noch eine, dann noch eine. Jede klingt für sich vernünftig. Zusammen schieben sie den Launch immer weiter nach hinten, während Budget und Runway schrumpfen.

Dahinter steckt eine Verwechslung. Mehr Funktionen fühlen sich nach Fortschritt an, sind aber oft das Gegenteil. Solange ein Produkt nicht in echten Händen liegt, produziert jede zusätzliche Funktion nur neue Annahmen statt Wissen.

Hilfreich ist hier Disziplin beim Weglassen. Leg den einen Kernablauf fest, der stimmen muss, und schieb den Rest bewusst auf später. Ein Produkt, das in acht Wochen etwas über seine Nutzer lernt, schlägt eines, das nach acht Monaten zum ersten Mal Feedback bekommt.

Der Betrieb wird nicht mitgedacht

Dieser Grund erwischt Projekte, die alles richtig zu machen schienen. Das Produkt ist gebaut, der Launch lief gut, und dann beginnt der eigentliche Härtetest: der laufende Betrieb. Ein SaaS ist kein Projekt mit Enddatum, sondern ein Dienst, der jeden Tag funktionieren muss.

Ohne Monitoring merkt niemand, dass die Anmeldung seit Stunden klemmt, ausser den Nutzern, die verärgert abspringen. Ohne Backups ist ein einziger Fehler endgültig. Aus einer offenen Sicherheitslücke wird ohne Updates irgendwann ein Vorfall mit Anwalt. Und wenn die Nutzerzahl steigt, bricht eine Architektur, die nie für Last gedacht war.

An dieser Stelle steigen reine Bau-Dienstleister aus. Sie liefern ab und sind weg, der Betrieb stand nie im Angebot. Wir behandeln den Betrieb von Tag eins als Teil der Architektur, nicht als spätere Zutat. Als Operator-Entwickler bauen wir nur, was wir auch selbst betreiben können, und übernehmen Hosting, Monitoring, Updates und Support als festen Teil der Arbeit. Wie das konkret aussieht, zeigt unsere SaaS-Produktentwicklung.

Code, den niemand mehr anfassen kann

Ein SaaS lebt davon, dass es sich weiterentwickeln lässt. Wenn jede kleine Änderung zur Operation am offenen Herzen wird, ist das Produkt faktisch eingefroren. Dahin kommt man, wenn unter Zeitdruck Abkürzungen genommen werden, die nie jemand aufräumt, oder wenn das ganze Wissen in einem einzigen Kopf steckt, der irgendwann geht.

Nah dran liegt der Lock-in. Du kommst an deinen eigenen Code, deine Daten oder deinen Anbieter nicht mehr heran, ohne alles neu zu bauen. Dann entscheidet nicht mehr dein Bedarf über den nächsten Schritt, sondern die Abhängigkeit.

Die Antwort ist unspektakulär und wirkt trotzdem: nachvollziehbarer Code, brauchbare Dokumentation und eine saubere Übergabe von Anfang an. Du sollst dein Produkt jederzeit weitergeben oder selbst weiterführen können, ohne dass etwas auseinanderfällt. Warum wir lieber individuell und übergebbar bauen als auf einen Baukasten zu setzen, liest du in Standardsoftware oder Individualentwicklung.

Ein Produkt ohne Weg zum Kunden

Auch ein technisch herausragendes SaaS scheitert, wenn niemand es findet oder niemand dafür zahlt. Bau es, und sie werden kommen ist kein Plan, sondern eine Hoffnung. Vertrieb, Preismodell und Sichtbarkeit gehören zum Produkt, nicht erst in die Zeit nach dem Launch.

Oft wird das Pricing zu spät und zu zaghaft angegangen. Ein Preis, der die Kosten nicht deckt, oder ein Modell, das niemand versteht. Genauso oft fehlt ein verlässlicher Kanal, über den neue Nutzer das Produkt überhaupt entdecken.

Die Antwort ist, von Anfang an mitzudenken, wer zahlt und wie diese Menschen dich finden. Ein Produkt mit klarem Preis und einem funktionierenden Kanal schlägt das technisch schönste SaaS ohne beides.

Wann sich ein SaaS gar nicht lohnt

Manchmal ist die beste Entscheidung, kein SaaS zu bauen. Wenn nur eine Handvoll Firmen dein Problem hat, trägt ein wiederkehrendes Mietmodell die Entwicklung selten. Dann ist ein einmaliges Projekt oder eine schlanke Individuallösung der klügere Weg, auch finanziell. Wenn dein Vorteil allein im Vorsprung liegt und sich in zwei Wochen nachbauen lässt, kauft dir niemand den Betrieb und die Pflege ab.

Und wenn du das Produkt nach dem Launch weder selbst betreiben noch betreiben lassen willst, baust du auf Sand. Ein SaaS ohne jemanden, der sich dauerhaft kümmert, ist eines der fünf Muster oben, nur von Anfang an eingebaut. In all diesen Fällen sagen wir das lieber vorher als nach drei Monaten Bauzeit.

So erkennst du die Warnzeichen früh

Die meisten dieser Gründe kündigen sich an. Fünf klare Fragen reichen, um zu sehen, ob ein Projekt in eine der Fallen läuft:

• Habt ihr eure zentrale Annahme schon an echten Nutzern geprüft, oder glaubt ihr nur, dass sie stimmt?
• Wisst ihr, welche eine Funktion zum Start wirklich reichen würde, oder wächst die Liste ständig?
• Steht fest, wer das Produkt nach dem Launch betreibt, überwacht und aktualisiert?
• Könnte ein neues Team euren Code übernehmen, ohne bei null anzufangen?
• Wisst ihr, wer zahlt und wie diese Leute euch finden?

Wer eine dieser Fragen nicht klar beantworten kann, hat eine konkrete Baustelle. Die lässt sich angehen, bevor sie zum Grund fürs Scheitern wird.

Scheitern folgt einem Muster, und Muster lassen sich brechen

So verschieden die fünf Gründe wirken, sie teilen einen Kern. Es wird zu lange auf Annahmen gebaut, statt früh zu prüfen. Am Markt vorbei, am Betrieb vorbei, am Kunden vorbei. Das ist die gute Nachricht, denn ein Muster lässt sich durchbrechen.

Prüfe früh, halte den Kern klein, denk den Betrieb von Anfang an mit und behalte die Kontrolle über deinen Code. Wer so vorgeht, bekommt kein garantiert erfolgreiches Produkt, aber er scheitert nicht mehr an den vermeidbaren Gründen. Wie wir Produkte so bauen und betreiben, dass sie diese Fallen umgehen, liest du auf unserer Seite zur SaaS-Produktentwicklung.