Warum Software nach dem Launch teuer wird

Warum Software nach dem Launch erst richtig teuer wird

Wenn ein Software-Projekt live geht, fühlt sich das an wie der Schlusspfiff. Budget verplant, Team feiert, Auftraggeber hakt die Zeile ab. Hier liegt das Missverständnis, das später Geld kostet. Der Launch ist kein Endpunkt. Er ist der Moment, in dem deine Software anfängt zu leben: echte Umgebung, echte Nutzer, echte Daten, echte Lastspitzen. Und ab jetzt entstehen die Kosten, die in keiner Projektkalkulation auftauchen.

Dieser Artikel zeigt dir, woraus diese Kosten bestehen, wie sie sich aufstauen und wie du den Betrieb von Anfang an so planst, dass er bezahlbar bleibt. Das ist keine Schwarzmalerei. Es ist die zweite Hälfte der Rechnung, und es lohnt sich, sie zu kennen, bevor sie eintrifft.

Total Cost of Ownership: die Rechnung, die niemand stellt

Für teure Anschaffungen gibt es in der Industrie einen Begriff: Total Cost of Ownership, kurz TCO. Gemeint sind die Gesamtkosten über die ganze Lebensdauer, nicht nur der Kaufpreis. Beim Auto ist der Kaufpreis der kleinere Posten. Versicherung, Treibstoff, Service, Reifen, Wertverlust summieren sich über Jahre zu einem Mehrfachen. Bei Software ist es dasselbe, nur sind die laufenden Kosten deutlich schlechter sichtbar.

Die Bauphase ist der Kaufpreis. Sie hat ein Datum, eine Offerte, eine Rechnung. Der Betrieb ist ein Strom: Hosting, Wartung, Sicherheitsupdates, Support, Anpassungen, Weiterentwicklung. Über die Lebensdauer einer Anwendung übersteigt dieser Strom die einmaligen Baukosten regelmässig, oft um ein Mehrfaches. Wer nur die Bauphase budgetiert, plant den kleineren Teil der Rechnung und tut so, als wäre es die ganze.

Der Denkfehler ist nachvollziehbar. Eine Offerte für den Bau kannst du anfassen. Der Betrieb ist diffus und liegt in der Zukunft, und genau das macht ihn gefährlich. Was nicht budgetiert ist, wird nicht eingeplant, und was nicht eingeplant ist, trifft dich unvorbereitet. Wer früh in Total Cost of Ownership statt nur in Baukosten denkt, entscheidet auch klüger, was überhaupt gebaut werden soll.

Der Wartungs-Schock: warum fertige Software trotzdem Arbeit macht

Eine verbreitete Annahme: Wenn die Software einmal funktioniert, läuft sie weiter. Bei einem Möbelstück stimmt das. Bei Software nicht, weil das Fundament unter ihr ständig in Bewegung ist.

Deine Anwendung steht nicht für sich. Sie sitzt auf einem Betriebssystem, nutzt eine Datenbank, hängt an Frameworks, Bibliotheken und externen Diensten wie Zahlungsanbietern oder E-Mail-Versand. Diese Schichten werden weiterentwickelt, bekommen Updates und werden irgendwann abgekündigt. Eine Bibliothek, die heute aktuell ist, gilt in zwei Jahren als veraltet. Eine Schnittstelle, die du heute nutzt, kann der Anbieter morgen abschalten. Browser ändern ihr Verhalten, Sicherheitslücken werden bekannt und müssen geschlossen werden.

Kurz: Selbst wenn sich an deiner Software nichts ändert, ändert sich alles um sie herum. Stillstand ist deshalb keine Option, sondern schleichender Verfall. Spielst du ein Jahr lang keine Updates ein, wartet danach kein kleines Update auf dich, sondern ein Berg aufgeschobener Aktualisierungen, die sich gegenseitig blockieren. Aus einer Stunde Routinepflege im Monat wird ein mehrwöchiges Sanierungsprojekt. Diesen Sprung nennen wir den Wartungs-Schock. Die Pflege verschwindet nicht, wenn du sie aufschiebst. Sie wird nur teurer.

Technische Schulden: der Zins auf schnelle Entscheidungen

Dicht daneben liegt ein Begriff, der den Kern vieler Kostenexplosionen erklärt: technische Schulden. Das Bild stammt aus der Finanzwelt und passt verblüffend gut. Wer beim Bauen eine Abkürzung nimmt, um schneller fertig zu sein, leiht sich Zeit. Diese Schuld wird verzinst, und der Zins fällt bei jeder künftigen Änderung an.

Ein Beispiel. Beim Bau eines MVP löst das Team die Benutzerverwaltung schnell und simpel, ohne saubere Trennung der Zuständigkeiten. Zum Start ist das vernünftig, denn Geschwindigkeit zählt mehr als Eleganz. Ein Jahr später soll eine Rollenverwaltung dazu. Jetzt rächt sich die Abkürzung: Weil alles ineinander verwoben ist, dauert die eigentlich kleine Erweiterung dreimal so lange wie geplant. Das ist der Zins, und du zahlst ihn rückwirkend.

Technische Schulden sind nicht grundsätzlich schlecht. Wie bei echtem Kredit kann es klug sein, sich gezielt etwas zu leihen, um früher am Markt zu sein. Brenzlig wird es erst, wenn niemand mitschreibt, welche Schulden aufgenommen wurden, und niemand sie je zurückzahlt. Dann wächst der Zinsberg unbemerkt, bis jede neue Funktion quälend langsam wird und Entwickler vor jeder Änderung zögern, weil sie nicht wissen, was sie damit kaputtmachen. Dieser Zustand steckt hinter vielen SaaS-Projekten, die nach gutem Start ins Stocken geraten.

Die Gegenmittel sind unspektakulär und wirken trotzdem. Mach Schulden sichtbar, statt sie zu verstecken. Notiere bei jeder Abkürzung, was vereinfacht wurde und unter welchen Bedingungen es ausgebaut gehört. Reserviere regelmässig einen Teil der Entwicklungszeit fürs Zurückzahlen, statt nur Neues draufzustapeln.

Kein Betriebsplan: wenn im Ernstfall niemand zuständig ist

Viele Projekte haben einen detaillierten Plan für den Bau und keinen einzigen Satz zum Betrieb. Das ist, als würdest du ein Haus bauen und nie klären, wer heizt, putzt, das Dach kontrolliert und die Rechnungen zahlt. Ein Betriebsplan beantwortet die Fragen, die nach dem Launch zählen.

Wer ist erreichbar, wenn um drei Uhr nachts der Zahlungsdienst ausfällt? Wer entscheidet, ob ein Sicherheitsupdate sofort eingespielt werden muss? Wo liegen die Backups, und hat je jemand getestet, ob sich daraus wirklich wiederherstellen lässt? Wer behält im Blick, dass Zertifikate und Domains rechtzeitig verlängert werden? Wie schnell muss ein Ausfall behoben sein, und was kostet jede Stunde Stillstand das Geschäft? Fünf Fragen, und in vielen Projekten kennt niemand die Antworten.

Fehlt der Plan, landet die Zuständigkeit im Ernstfall bei dem, der gerade greifbar ist. Meist ohne Vorbereitung, ohne Zugänge, ohne Überblick. So wird aus einem kleinen Problem ein grosses, einfach weil vorher niemand festgelegt hat, wie man damit umgeht. Ein Betriebsplan kostet in der Erstellung wenig und spart im Ernstfall viel, weil er aus Improvisation Routine macht. Diese Routine ist der Kern von Produkt-Betrieb als eigener Disziplin: Software am Laufen zu halten ist eine Aufgabe für sich, kein Nebenprodukt des Bauens.

Ohne Monitoring wird jede Störung zum Notfall

Zwischen Teams, die wissen, wie es ihrer Software gerade geht, und Teams, die es nicht wissen, liegt ein messbarer Unterschied. Er heisst Monitoring.

Ohne Monitoring erfährst du von Problemen durch deine Nutzer. Jemand schreibt verärgert, dass die Bestellung nicht durchgeht. Ein Kunde ruft an, weil die Seite seit Stunden hängt. Bis dahin ist der Schaden längst da, und du startest aus dem Stand. Du weisst nicht, seit wann es klemmt, woran es liegt, ob nur eine Funktion betroffen ist oder das ganze System. So wird jede Störung zum Notfall, weil sie dich überrascht und du erst im Dunkeln tappst, bevor du handeln kannst.

Mit Monitoring dreht sich die Reihenfolge um. Du siehst die Antwortzeiten steigen, bevor die Seite ganz steht. Du bekommst eine Meldung, sobald die Fehlerrate anspringt, und greifst ein, während die meisten Nutzer noch nichts merken. Du erkennst, wenn ein Server an seine Grenze kommt, bevor er umfällt. Monitoring verwandelt Überraschungen in Vorwarnungen, und eine Vorwarnung lässt sich um ein Vielfaches billiger behandeln als ein Totalausfall mitten im Tagesgeschäft.

Dazu gehört mehr als ein Diagramm an der Wand. Brauchbares Monitoring schickt Alarme an die richtige Person zur richtigen Zeit, ohne sie mit Fehlalarmen abzustumpfen. Es führt Protokolle, mit denen sich eine Störung im Nachhinein rekonstruieren lässt. Und es beschränkt sich auf die paar Kennzahlen, die wirklich zählen, statt auf hundert, die niemand liest. Der Aufwand dafür ist klein gegen das, was ein unbemerkter Ausfall an Umsatz und Vertrauen kostet.

Wann sich der Aufwand nicht lohnt

Nicht jede Anwendung verdient denselben Betriebsaufwand. Ein internes Tool, das eine Handvoll Leute zweimal im Monat nutzt, braucht keine Alarmkette und keinen Bereitschaftsdienst um drei Uhr nachts. Ein Wochenend-Prototyp, der eine Idee testet und danach vermutlich gelöscht wird, braucht keine Backup-Strategie mit Wiederherstellungstest. Der nüchterne Massstab ist nicht Vollständigkeit, sondern Verhältnis: Was kostet ein Ausfall, und wie wahrscheinlich ist er?

Für Software, an der dein Geschäft hängt, fällt die Antwort klar aus, und der Betriebsaufwand zahlt sich aus. Für ein Experiment ohne echte Nutzer ist eine schlanke Lösung das Richtige, und voller Betriebsapparat wäre Verschwendung. Wichtig ist nur, dass du die Entscheidung bewusst triffst, statt den Betrieb einfach wegzulassen und zu hoffen. Genau die Hoffnung ist es, die später teuer wird.

Wer betreibt, baut anders

Uns ist dieses Thema nicht aus der Beratung vertraut, sondern aus dem eigenen Alltag. Wir bauen Software bei Wertstifter nicht nur, wir betreiben unsere eigenen Produkte selbst, etwa Wortfreunde und Reazon. Das verändert, wie wir bauen. Wer eine Anwendung danach selbst am Laufen halten muss, trifft andere Entscheidungen als jemand, der nach dem Launch verschwindet.

Konkret: Wir wählen Technik, die wir auch in zwei Jahren noch warten können, statt der neuesten Spielerei. Wir bauen Monitoring von Anfang an ein, weil wir selbst die Anrufe um drei Uhr nachts bekämen. Wir schreiben technische Schulden mit, weil wir sie sonst selbst abtragen müssten. Dieser Operator-Blick trennt eine Software, die zum Launch glänzt, von einer, die auch im dritten Betriebsjahr noch bezahlbar läuft. Wer vor der Wahl steht, selbst zu bauen, eine Agentur zu beauftragen oder mit einem Produktstudio zu arbeiten, sollte deshalb nicht nur fragen, wer am günstigsten baut, sondern wer danach mitdenkt.

So bleibt die zweite Hälfte der Rechnung klein

Software wird nach dem Launch teuer, wenn du den Betrieb dem Zufall überlässt. Sie bleibt bezahlbar, wenn du ihn von Anfang an mitdenkst. Rechne die Total Cost of Ownership schon vor dem Bau, nicht nur den Kaufpreis. Plane Wartung als festen Posten, damit aus aufgeschobener Pflege kein Wartungs-Schock wird. Schreibe technische Schulden mit und zahle sie in kleinen Raten zurück, statt den Zinsberg wachsen zu lassen. Lege einen Betriebsplan an, der klärt, wer im Ernstfall was tut. Und richte Monitoring ein, damit du von Problemen erfährst, bevor deine Nutzer es tun.

Keiner dieser Schritte ist für sich gross oder teuer. Teuer wird ihr Fehlen. Die gute Nachricht: Die zweite Hälfte der Rechnung ist planbar. Du musst sie nur stellen, bevor sie dich überrascht.