Was kostet der Betrieb eines SaaS pro Monat?

Warum der Betrieb in keinem Angebot steht

Wenn du ein SaaS bauen lässt, dreht sich fast jedes Gespräch um die Entwicklung. Funktionen, Design, Termine, Festpreis. Logisch, das ist der sichtbare Teil. Was der SaaS-Betrieb pro Monat kostet, fällt unter den Tisch, weil er erst an dem Tag anfängt, an dem das Produkt live geht. Das Angebot endet beim Launch. Die Betriebsrechnung kommt danach. Und zwar jeden Monat.

Betrieb meint alles, was passiert, damit dein Produkt morgen noch so läuft wie heute. Server, die nicht ausfallen. Daten, die nach einem Fehler wiederherstellbar sind. Sicherheitslücken, die zu sind, bevor jemand sie findet. Eine Stelle, an die deine Nutzer sich wenden, wenn etwas klemmt. Nichts davon ist einmalig erledigt. Das läuft, solange das Produkt lebt.

Wir sehen das von zwei Seiten. Wir bauen Produkte für Kunden und betreiben gleichzeitig eigene, etwa die Lernplattform Wortfreunde und das CMS Reazon. Wer selbst rangeht, wenn nachts ein Server streikt, rechnet Betrieb anders als ein Haus, das nach dem Launch zum nächsten Projekt weiterzieht. Dieser Blick steckt in jedem der fünf Posten unten.

Hosting: wo dein Produkt wohnt

Hosting ist die Grundmiete. Irgendwo muss dein Code laufen, deine Datenbank stehen, dein Traffic ankommen. Den Posten nennen die meisten zuerst, und er schwankt am stärksten von allen.

Was ihn nach oben treibt, ist nicht die Zahl deiner Nutzer, sondern was sie tun. Ein Tool, das Text speichert und Formulare verarbeitet, braucht fast nichts. Sobald Bilder, Videos, Dateien oder rechenintensive Aufgaben dazukommen, ziehen Rechenleistung, Speicher und Datentransfer spürbar an. Dann die Verfügbarkeit: Ein internes Werkzeug verkraftet ein paar Minuten Ausfall und läuft auf einer einzelnen Maschine. Ein Produkt, das rund um die Uhr erreichbar sein muss, braucht Redundanz, also mehrere Server, die sich gegenseitig auffangen, plus eine Lastverteilung davor. Redundanz verdoppelt im Kern die Infrastruktur. Das siehst du auf der Rechnung.

Dazu kommt die Architektur, die beim Bauen entstanden ist. Wie ihr ein MVP aufsetzt, entscheidet mit, was der Betrieb später kostet, weshalb die besten Wege, ein MVP zu bauen, immer auch eine Betriebsfrage sind. Eine schlanke, gut geschnittene Anwendung skaliert günstig. Eine, die früh auf zehn Komponenten verteilt wurde, zahlt ab Tag eins Grundkosten für Teile, die kaum jemand nutzt.

Die Bandbreite reicht von wenigen Franken im Monat für ein kleines, ruhiges Produkt bis zu einem Vielfachen davon, sobald Last, Daten und Verfügbarkeitsansprüche zusammenkommen. Merk dir die Mechanik statt der Zahl: Hosting wächst mit der Nutzung, nicht mit der Zeit. Es ist der einzige Posten, der bei Erfolg automatisch teurer wird. Das ist ein gutes Problem.

Monitoring: bemerken, bevor der Kunde anruft

Monitoring beantwortet die Frage, ob dein Produkt gerade wirklich funktioniert. Ohne erfährst du vom Ausfall durch den ersten verärgerten Nutzer, und das ist der teuerste Weg, es zu erfahren.

Drei Dinge prüft es laufend: Ist das Produkt erreichbar, antwortet es schnell genug, stapeln sich im Hintergrund Fehler? Dazu Alarme, die jemanden wecken, wenn ein Schwellwert reisst. Der Aufwand fällt in zwei Töpfe. Da sind die Werkzeugkosten für Dienste, die Verfügbarkeit prüfen, Fehler sammeln und Logs durchsuchbar machen. Und da ist der Mensch dahinter, denn ein Alarm nützt nichts, wenn niemand bereitsteht, der reagiert.

Teuer macht Monitoring vor allem die geforderte Reaktionszeit. Darf ein Ausfall über Nacht warten, brauchst du keine Rufbereitschaft. Muss das Produkt auch sonntags um drei laufen, braucht es jemanden in Bereitschaft, und Bereitschaft kostet auch dann, wenn nichts passiert. Wer ein Produkt nur baut, richtet vielleicht zwei, drei Checks ein und ist fertig. Wer es betreibt, baut das Monitoring so, dass der Alarm ihn selbst nachts trifft, und achtet deshalb auf wenige, aussagekräftige Signale statt auf Lärm, den irgendwann keiner mehr ernst nimmt.

Backups: die Versicherung, die du hoffentlich nie brauchst

Backups sind Sicherungskopien deiner Daten. Der Speicher dafür ist billig, oft der kleinste Posten überhaupt. Trotzdem entscheidet kaum etwas anderes im Ernstfall so klar über die Existenz eines Produkts, denn verlorene Kundendaten holst du nicht zurück.

Der Preis hängt nicht am Speichern, sondern an der Anforderung dahinter. Zwei Fragen bestimmen ihn: Wie viel Datenverlust ist im Notfall verkraftbar, und wie schnell muss alles wieder da sein? Ein tägliches Backup ist simpel. Dürfen im schlimmsten Fall nur ein paar Minuten Arbeit verloren gehen, brauchst du häufigere oder kontinuierliche Sicherung, und die ist aufwändiger. Der Teil, den fast alle übersehen, ist die Wiederherstellung. Ein Backup, das nie zurückgespielt wurde, ist eine Vermutung, keine Sicherheit. Geprüfte Wiederherstellung kostet regelmässig Zeit, trennt aber das echte Backup von der leeren Hoffnung.

Viele unterschätzen den Posten, weil er im Alltag unsichtbar bleibt. Bis er es nicht mehr tut. Genau deshalb gehört er zu den stillen Gründen, warum SaaS-Projekte scheitern: selten am fehlenden Backup, fast immer am ungetesteten.

Updates: Stillstand ist keine Option

Kein SaaS steht still, auch wenn niemand neue Funktionen baut. Jedes Produkt steht auf fremdem Code: Sprache, Bibliotheken, Datenbank, das Betriebssystem des Servers. Diese Bausteine entwickeln sich laufend weiter, und laufend werden in ihnen Sicherheitslücken gefunden und geschlossen. Wer nicht aktualisiert, sammelt mit der Zeit bekannte Schwachstellen, bis das Produkt zur offenen Tür wird.

Updates lassen sich am leichtesten verschieben und rächen sich dafür am bittersten. Drei Dinge bestimmen den Aufwand. Die Zahl der Abhängigkeiten, denn je mehr fremde Bausteine, desto mehr potenzielle Updates. Die Disziplin beim Bauen, denn eine Anwendung mit automatisierten Tests lässt sich aktualisieren und sofort prüfen, ob danach noch alles läuft, während ohne Tests jedes Update zum Blindflug wird. Und der Rückstand. Wer regelmässig in kleinen Schritten aktualisiert, hat überschaubaren Aufwand. Wer zwei Jahre wartet, steht vor einem Berg, weil sich Versionssprünge gegenseitig blockieren und aus dem Update ein eigenes kleines Projekt wird.

Darum ist regelmässige Pflege günstiger als gestaute, auch wenn sie sich im Monatsbudget erst nach unnötiger Ausgabe anfühlt. Der Aufwand verschwindet nicht, wenn du ihn aufschiebst. Er wird grösser und unberechenbarer.

Support: die menschliche Seite des Betriebs

Support ist die Stelle, an die deine Nutzer sich wenden, wenn etwas nicht funktioniert oder unklar ist. Technisch kein Server-Thema, in der Praxis ein fester Betriebsposten, weil jedes Produkt mit echten Menschen Fragen erzeugt.

Die Kosten hängen an zwei Hebeln. Erstens die Menge der Anfragen, und die hängt daran, wie verständlich das Produkt gebaut ist. Ein Werkzeug, das sich selbst erklärt, erzeugt wenig Support. Eines voller Stolperstellen erzeugt viel, Monat für Monat. Zweitens die Tiefe der Anfragen. Eine simple Wie-mache-ich-X-Frage ist schnell beantwortet. Ein Fehler, der erst reproduziert und im Code gesucht werden muss, bindet Entwicklungszeit. Support und Entwicklung lassen sich im Betrieb nicht sauber trennen, denn die schwierigen Tickets landen am Ende bei denen, die das Produkt gebaut haben.

Wer baut und betreibt, hat hier einen Vorteil, der über Kosten hinausgeht. Support-Anfragen sind Feedback aus dem echten Einsatz. Kommt dieselbe Frage zehnmal, ist das kein Support-Problem, sondern ein Hinweis, dass eine Stelle im Produkt schlecht gelöst ist. Diese Schleife aus betreiben, zuhören und nachbessern ist mehr wert als die paar eingesparten Support-Minuten.

Wann sich ein fester Betriebspartner nicht lohnt

Nicht jedes Produkt braucht den vollen Apparat. Ein internes Tool für fünf Kolleginnen, das untertags läuft und nachts ruhig daliegt, kommt mit einem einzelnen Server, täglichem Backup und ohne Rufbereitschaft aus. Da wäre eine 24/7-Betriebspauschale rausgeworfenes Geld. Auch wer technisches Personal im Haus hat, das Updates und Monitoring sauber selbst stemmt, braucht uns dafür nicht. Ein Betriebspartner lohnt sich, sobald Ausfälle echtes Geld oder Vertrauen kosten, sobald Daten kritisch werden, oder sobald niemand im Team nachts ans Telefon will. Bis dahin reicht oft weniger, als ein Angebot dir verkaufen möchte. Frag im Zweifel, welche der fünf Treiber für dich überhaupt scharf sind.

Was die Summe am Ende bestimmt

Die monatlichen Betriebskosten kommen nicht aus einer Preisliste, sondern aus Entscheidungen, die grösstenteils schon beim Bauen fallen. Eine schlanke Anwendung mit Tests, sauberer Architektur und ohne überflüssige Infrastruktur ist im Betrieb günstig. Eine, die schnell und ohne Rücksicht auf später entstanden ist, erzeugt jeden Monat Reibung, die als Betriebskosten zurückkommt. Betrieb ist insofern der Spiegel der Bauqualität.

Die nützlichste Frage an ein Angebot lautet deshalb nicht Was kostet die Entwicklung?, sondern Was kostet es, das hier zwei Jahre lang laufen zu lassen?. An dieser Frage entscheidet sich auch, ob sich eigenes SaaS für ein KMU lohnt oder nicht. Wer Entwicklung und Betrieb getrennt denkt, zahlt die Trennung später. Wir verbinden beides und übernehmen den Produkt-Betrieb für Software, die wir gebaut haben, weil sich erst im Betrieb zeigt, ob ein Produkt etwas taugt.

Eine belastbare Hausnummer pro Monat bekommst du erst, wenn die fünf Treiber für dein konkretes Produkt geklärt sind: wie viel Last und welche Verfügbarkeit, wie schnell die Reaktion im Notfall, wie kritisch die Daten, wie diszipliniert der Code, wie erklärungsbedürftig das Produkt. Wer dir vorher eine Zahl nennt, rät. Wer mit dir diese fünf Fragen durchgeht, plant.