Was Software nach dem Launch kostet

Die meisten Softwareprojekte werden mit einer einzigen Zahl geplant: dem Entwicklungsbudget. Das ist ungefähr so, als würde man ein Auto nach dem Kaufpreis beurteilen und Sprit, Versicherung, Reifen und Werkstatt weglassen.

Bei Software ist der Unterschied sogar größer, weil sie ohne Zuwendung nicht einfach langsamer wird – sie hört irgendwann auf zu funktionieren. Nicht wegen Verschleiß, sondern weil sich die Welt um sie herum bewegt: Betriebssysteme, Browser, Bibliotheken, Gesetze, Schnittstellen.

Dieser Beitrag rechnet nach, was nach dem Launch tatsächlich anfällt.

Die vier Kostenblöcke

Betrieb

Server, Datenbank, Sicherungen, Dienste. Bei einer typischen Geschäftsanwendung mit einigen hundert Nutzern zwischen 60 und 190 € im Monat, also grob 700 bis 2.300 € im Jahr. Das ist meist der kleinste Posten und der einzige, den alle einplanen.

Wartung

Hier wird es interessant, weil dieser Posten unsichtbar ist. Er besteht aus Arbeiten, die von außen nichts verändern:

Abhängigkeiten aktualisieren. Eine moderne Anwendung nutzt Dutzende bis Hunderte fremder Bausteine. Die entwickeln sich weiter, und in ihnen werden regelmäßig Sicherheitslücken gefunden. Wer ein Jahr nicht aktualisiert, hat keinen Rückstand von einem Jahr – er hat einen Rückstand, der exponentiell teurer wird, weil sich Umstellungen häufen und aufeinander aufbauen.

Laufzeitumgebungen aktualisieren. Sprachversionen und Datenbanken haben Wartungszeiträume. Läuft der aus, gibt es keine Sicherheitsaktualisierungen mehr. Alle zwei bis drei Jahre steht damit ein größerer Schritt an.

Plattformvorgaben erfüllen. Bei mobilen Apps verlangen beide Stores regelmäßig, dass gegen eine aktuelle Systemversion gebaut wird. Wer das versäumt, kann keine Aktualisierung mehr einreichen. Die App verschwindet nicht sofort, aber sie ist eingefroren.

Browser und Geräte. Neue Bildschirmgrößen, geänderte Standardeinstellungen, neue Datenschutzregeln in Browsern. Nichts davon ist dramatisch, alles davon kostet Stunden.

Faustregel: 15 bis 20 Prozent der ursprünglichen Entwicklungskosten pro Jahr. Bei einem Projekt für 50.000 € sind das 7.500 bis 10.000 € jährlich, nur um den Stand zu halten. Diese Zahl überrascht regelmäßig, und sie ist trotzdem eher konservativ.

Sicherheit

Teilweise in der Wartung enthalten, aber mit eigener Dringlichkeit. Eine kritische Lücke in einer verbreiteten Bibliothek wartet nicht auf den nächsten Sprintwechsel. Sie braucht eine Reaktion innerhalb von Tagen, manchmal Stunden.

Das setzt zweierlei voraus: dass jemand solche Meldungen überhaupt mitbekommt, und dass jemand verfügbar ist, der reagieren kann. Beides sollte vertraglich geregelt sein, sonst stellt sich die Frage erst im Ernstfall.

Dazu kommt bei personenbezogenen Daten die Meldepflicht: Ein Datenschutzvorfall muss innerhalb von 72 Stunden der Aufsichtsbehörde gemeldet werden. Wer dann erst herausfinden muss, wer Zugriff auf welche Protokolle hat, verliert entscheidende Zeit.

Weiterentwicklung

Der größte und am schwersten planbare Posten. Kein Produkt bleibt nach dem Launch stehen. Nutzer wünschen sich Dinge, Prozesse ändern sich, Gesetze ändern sich, Wettbewerber ziehen nach.

Was wir in der Praxis sehen: Im ersten Jahr nach dem Launch fallen typischerweise 30 bis 50 Prozent der ursprünglichen Entwicklungskosten für Weiterentwicklung an. Nicht, weil schlecht gebaut wurde, sondern weil der Kontakt mit echten Nutzern immer Dinge zutage fördert, die vorher niemand wissen konnte.

Die Fünfjahresrechnung

Nehmen wir eine Branchenlösung, Entwicklung 60.000 €:

Jahr	Betrieb	Wartung	Weiterentwicklung	Summe
1 (Launch)	1.200 €	6.000 €	20.000 €	27.200 €
2	1.400 €	9.000 €	12.000 €	22.400 €
3	1.500 €	9.000 €	10.000 €	20.500 €
4	1.700 €	12.000 €	10.000 €	23.700 €
5	1.800 €	9.000 €	10.000 €	20.800 €
Gesamt	7.600 €	45.000 €	62.000 €	114.600 €

Die Entwicklung kostete 60.000 €. Die folgenden fünf Jahre kosten fast das Doppelte.

Im vierten Jahr ist die Wartung erhöht – das ist der typische größere Schritt, wenn eine Laufzeitumgebung ihr Wartungsende erreicht. Solche Sprünge kommen regelmäßig und lassen sich ungefähr, aber nicht genau vorhersagen.

Diese Zahlen sind Erfahrungswerte, keine Naturgesetze. Nach oben und unten sind Abweichungen um die Hälfte normal. Was sich aus ihnen ableiten lässt, ist trotzdem robust: Wer nur das Entwicklungsbudget plant, plant weniger als die Hälfte.

Was die Folgekosten senkt

Nicht alles davon ist schicksalhaft. Vier Entscheidungen zur Bauzeit machen einen messbaren Unterschied.

Wenige Abhängigkeiten. Jede eingebundene Bibliothek ist ein Versprechen an die Zukunft. Bei kleinen Hilfsfunktionen ist selbst schreiben oft billiger als dauerhaft pflegen. Bei großen Bausteinen – Datenbankzugriff, Authentifizierung – gilt das Gegenteil.

Langweilige Technik. Ein Werkzeug, das seit acht Jahren existiert und in fünf Jahren noch existieren wird, ist eine bessere Entscheidung als das, was gerade neu ist. Sie finden Entwickler dafür, es gibt Antworten auf Fragen, und die Umstellungsschritte sind dokumentiert.

Automatisierte Tests dort, wo es wehtut. Nicht überall – das kostet mehr, als es bringt. Aber an den Stellen, an denen Fehler Geld oder Vertrauen kosten: Abrechnung, Rechteprüfung, Datenmigration. Diese Tests sind der Grund, warum man eine Aktualisierung an einem Nachmittag machen kann statt in einer Woche.

Dokumentation, die stimmt. Eine Anleitung, mit der ein fremder Entwickler die Anwendung aufsetzen und ausliefern kann. Ohne sie kostet jeder Personalwechsel – bei Ihnen oder beim Dienstleister – mehrere Tage Einarbeitung.

Der Fall, den niemand plant

Der Dienstleister ist nicht mehr verfügbar. Er hat keine Kapazität, er stellt den Betrieb ein, die Zusammenarbeit endet im Streit.

Das ist der Moment, in dem sich entscheidet, ob Sie ein Produkt haben oder eine Abhängigkeit. Die Fragen, die dann zählen:

• Liegt der Quellcode in einem Repository, auf das Sie Zugriff haben?
• Laufen die Server-, Store- und Dienstkonten auf Ihren Namen?
• Gibt es eine Anleitung, mit der jemand anderes das System aufsetzen kann?
• Haben Sie die Nutzungsrechte schriftlich – ausschließlich, unbefristet, mit Bearbeitungsrecht?

Wenn Sie eine dieser Fragen mit Nein beantworten, sollten Sie das klären, solange die Beziehung gut ist. Danach wird es zäh, und in manchen Fällen bleibt nur der Neubau.

Das ist auch der Grund, warum wir Produkte grundsätzlich in der Infrastruktur des Kunden einrichten und vollständig übergeben. Nicht aus Großzügigkeit, sondern weil die Alternative eine Abhängigkeit erzeugt, die niemand bewusst eingegangen ist.

Wie Sie das im Angebot prüfen

Drei Fragen, die Sie jedem Anbieter stellen sollten – und die Antworten sagen mehr über die Zusammenarbeit aus als die Preisliste:

1. Was kostet mich das Jahr zwei? Wer das nicht beantworten kann oder will, hat entweder nie ein Produkt über Jahre begleitet oder möchte die Zahl nicht nennen.
2. Was passiert, wenn wir nicht weitermachen? Eine gute Antwort beschreibt konkret, was übergeben wird. Eine schlechte weicht aus.
3. Welche Abhängigkeiten baut ihr ein, und warum? Die Antwort zeigt, ob jemand über den Launch hinaus denkt.

Was Sie mitnehmen sollten

Rechnen Sie ab dem ersten Tag mit den Folgejahren. Eine grobe Faustformel, die erstaunlich gut trägt: Die Gesamtkosten über fünf Jahre liegen bei etwa dem Zweieinhalbfachen der Entwicklungskosten.

Das ist kein Argument gegen das Projekt. Es ist ein Argument dafür, den Umfang der ersten Version klein zu halten. Jede Funktion, die Sie zu Beginn nicht bauen, kostet Sie fünf Jahre lang nichts an Wartung. Das ist der eigentliche Grund, warum ein sauber zugeschnittenes MVP nicht nur billiger startet, sondern dauerhaft billiger bleibt.

Support: der vergessene Kostenblock

In der Tabelle oben fehlt ein Posten, den fast alle übersehen: die Betreuung der Nutzer.

Sobald ein Produkt läuft, kommen Fragen. Die meisten sind keine Fehler, sondern Verständnisfragen – jemand findet eine Funktion nicht, jemand hat versehentlich etwas gelöscht, jemand will wissen, warum eine Zahl anders aussieht als erwartet.

Der Aufwand dafür hängt stärker von der Nutzerzahl ab als von der Softwarequalität. Als grober Anhaltspunkt: Bei einer Geschäftsanwendung mit hundert Nutzern fallen im ersten Jahr etwa zwei bis vier Stunden im Monat an, danach weniger. Bei einem Verbraucherprodukt mit zehntausend Nutzern ist es ein eigener Arbeitsplatz.

Zwei Dinge senken diesen Aufwand messbar. Erstens ein Ansprechpartner beim Kunden, der die Software gut kennt und die Hälfte der Fragen selbst beantwortet. Zweitens eine kurze, aktuelle Anleitung – nicht als Handbuch, sondern als Sammlung der zwölf häufigsten Fragen.

Wichtig ist, diesen Posten überhaupt zu benennen. Wer ihn nicht kalkuliert, leistet ihn trotzdem – nur unbezahlt, und dann ungern.

Schnittstellen altern schneller als alles andere

Wenn Ihr Produkt an Fremdsysteme angebunden ist, haben Sie einen Kostenblock, den Sie nicht kontrollieren.

Schnittstellen ändern sich. Manchmal angekündigt, manchmal nicht. Ein Zahlungsanbieter stellt eine Version ab, ein Warenwirtschaftssystem ändert ein Feldformat, eine Behördenschnittstelle bekommt neue Pflichtangaben. Jedes Mal ist das Arbeit, die Sie nicht geplant haben und die trotzdem erledigt werden muss, weil sonst ein Teil des Produkts stillsteht.

Drei Dinge helfen:

Die Anbindung kapseln. Der fremde Dienst wird an genau einer Stelle angesprochen, nicht an fünfzehn. Dann ist eine Umstellung ein Tag statt einer Woche.

Ankündigungen abonnieren. Die meisten Anbieter informieren über anstehende Änderungen. Diese Nachrichten müssen bei jemandem ankommen, der sie liest.

Ausfälle einplanen. Was passiert, wenn der fremde Dienst zwei Stunden nicht antwortet? Ein Produkt, das dann eine Fehlermeldung zeigt und nichts mehr kann, ist schlechter als eines, das den Vorgang vormerkt und später nachholt.

Bei Produkten mit mehreren Schnittstellen rechnen wir mit fünf bis zehn zusätzlichen Tagen pro Jahr, nur für Anpassungen an fremde Änderungen.

Wann sich ein Neubau lohnt

Irgendwann steht die Frage im Raum: weitermachen oder neu bauen? Sie wird meist zu spät gestellt und dann emotional beantwortet.

Nüchterne Anzeichen dafür, dass ein Neubau die günstigere Variante ist:

• Die Aufwandsschätzungen stimmen nicht mehr. Was früher zwei Tage dauerte, dauert jetzt zwei Wochen, ohne dass die Aufgabe größer geworden wäre.
• Niemand fasst bestimmte Stellen mehr an. Es gibt Bereiche im Code, um die alle einen Bogen machen, weil unklar ist, was kaputtgeht.
• Die Grundlage wird nicht mehr gepflegt. Ein Framework oder eine Sprachversion ohne Sicherheitsaktualisierungen ist ein Ablaufdatum, kein Zustand.
• Das fachliche Modell passt nicht mehr. Das Geschäft hat sich geändert, und jede neue Anforderung wird gegen die Struktur gebaut statt mit ihr.

Der letzte Punkt ist der einzige, der wirklich für einen Neubau spricht. Die ersten drei lassen sich meist schrittweise beheben – und schrittweise ist fast immer günstiger, weil das Produkt währenddessen weiterläuft.

Ein vollständiger Neubau bedeutet: Sie zahlen ein zweites Mal für Funktionen, die Sie bereits haben, und bekommen dafür monatelang nichts Neues. Wer diese Rechnung aufmacht, entscheidet sich häufig doch für den Umbau in Etappen.

Zwei Zahlen für Ihre Planung

Wenn Sie aus diesem Beitrag zwei Zahlen mitnehmen wollen:

15 bis 20 Prozent der Entwicklungskosten pro Jahr, nur um den Stand zu halten. Das ist der Boden. Darunter geht es nur, wenn jemand die Arbeit unbezahlt macht.

Das Zweieinhalbfache der Entwicklungskosten über fünf Jahre, inklusive Weiterentwicklung. Das ist der realistische Gesamtbetrag.

Beide Zahlen schwanken, aber sie schwanken um diese Mitte. Ein Angebot, das dauerhaft deutlich darunter verspricht, verschiebt die Kosten nur – in eine spätere Rechnung oder in eine Software, die irgendwann stillsteht.