Spis treści
Der Go-live ist nicht das Ende des Projekts, sondern der Anfang seiner Kosten
Ein Gespräch über eine Anwendung endet gewöhnlich beim Starttermin. Der Kunde erhält ein Angebot mit Etappen, Terminen und dem Preis für den Aufbau, und danach herrscht Stille. Das Dokument schweigt darüber, was am Tag nach dem Start passiert. Und genau dann beginnt die längste Lebensphase des Systems, jene, die länger dauert als die Entwicklung selbst und insgesamt mehr Geld verschlingt. Die Wartung ist keine Zugabe zum Projekt. Sie ist seine Fortsetzung.
Warum ist das so? Software nutzt sich nicht physisch ab, sie altert aber im Verhältnis zu ihrem Umfeld. Browser ändern sich, Framework-Versionen, Anforderungen der Betriebssysteme auf Smartphones, Bedingungen der Zahlungsanbieter, Datenschutzvorschriften. Die Anwendung steht still, die Welt um sie herum geht weiter, und der Abstand zwischen beiden wächst mit jedem Monat. Nach einem Jahr ohne Betreuung erzeugt selbst ein stabiles System Probleme, die niemand eingeplant hat.
Aus Sicht des Dienstleisters ist die Sache klar: Projektbudget und Wartungsbudget sind zwei getrennte Positionen, die unterschiedlich abgerechnet werden und eine unterschiedliche Funktion haben. Die erste ist einmalig und endlich, die zweite zyklisch und durchaus planbar, sofern sie jemand vorher durchrechnet. Nur spricht man in Verkaufsgesprächen vor allem über die erste, weil ein niedrigerer Umsetzungspreis im Angebotsvergleich besser aussieht. Und das ist nicht immer böser Wille. Häufiger fragt schlicht niemand danach.
Die Folgen können schmerzhaft sein. Ein System, das keine regelmäßige Aufmerksamkeit bekommt, altert schneller, als sich die Investition amortisieren kann. Kleine Störungen häufen sich, Nutzer verlieren das Vertrauen in das Werkzeug, und das Team auf Kundenseite beginnt, die Anwendung zu umgehen und zu Tabellenkalkulationen zurückzukehren (ich habe das öfter gesehen, als mir lieb ist). Im Extremfall zahlt das Unternehmen nach zwei Jahren ein zweites Mal für dasselbe, nur jetzt unter dem Titel “Neuentwicklung von Grund auf”. Diese Summe tauchte in der ursprünglichen Wirtschaftlichkeitsrechnung nie auf.
Woraus die Kosten für die Wartung einer Anwendung wirklich bestehen
Die Frage “Was kostet die Wartung einer Anwendung” hat keine einzelne Antwort, aber sie hat eine klare Struktur. Es gibt mehrere Bestandteile und jeder verhält sich anders: Ein Teil wächst linear mit dem Traffic, ein Teil ist fix, und ein Teil taucht sprunghaft auf, zu Zeitpunkten, die sich nicht auf den Tag genau vorhersagen lassen. Diese Aufschlüsselung in Kategorien bringt mehr als die Angabe einer Preisspanne, denn sie erlaubt zu prüfen, was in einem konkreten Angebot fehlt.
Die erste Ebene ist die Infrastruktur. Anwendungsserver, Datenbank, Speicherplatz für Dateien, Transfervolumen, Sicherungskopien und, was oft vergessen wird, eine separate Testumgebung, auf der Änderungen geprüft werden, bevor sie zu den Nutzern gelangen. Auf sie zu verzichten sieht nach Ersparnis aus. Bis zur ersten Störung, die durch eine direkt auf die Produktion eingespielte Korrektur ausgelöst wird.
Die zweite Ebene sind externe Dienste, meist im Abonnement oder nach Verbrauch abgerechnet. Zahlungs-Gateway, Karten, SMS-Versand, transaktionale E-Mails, Monitoring-Werkzeuge und seit Kurzem auch Sprachmodelle, bei denen die Rechnung von der Anzahl verarbeiteter Token abhängt. Der letzte Posten kann überraschen, denn er skaliert mit der Beliebtheit einer Funktion und nicht mit der Zahl der Konten im System.
Die dritte Ebene ist die Arbeit von Menschen. Monitoring und Reaktion auf Alarme, Aktualisierung von Bibliotheken, Behebung von Fehlern, die Nutzer melden, kleine funktionale Änderungen aus dem laufenden Geschäftsbedarf. Der flexibelste Posten der ganzen Aufstellung und, nun ja, genau der, an dem am häufigsten gespart werden soll.
Die vierte Ebene ist auf keiner Rechnung sichtbar, kostet bei einem Teil der Kunden aber real am meisten:
- Infrastruktur: Server, Datenbank, Storage, Transfer, Backups, Test- und Staging-Umgebung
- Lizenzen und externe APIs: Zahlungen, Karten, SMS, transaktionale E-Mails, nach Verbrauch abgerechnete KI-Modelle
- Arbeit des technischen Teams: Monitoring, Updates, Hotfixes, Support, kleine Verbesserungen
- Versteckte Kosten auf Kundenseite: Arbeitszeit der Mitarbeitenden für Tickets, Datenprüfung, Einarbeitung neuer Personen
- Risiko: Ausfallstunden, manuelles Nacharbeiten des Prozesses, verlorene Bestellungen
Das Bewusstsein für diese fünf Gruppen verändert die Art, ein Angebot zu lesen. Statt nach dem Preis fragen Sie nach dem Umfang.
Technische Schulden, also die Rechnung mit Verzögerung
Jedes Projekt, das in vernünftiger Zeit entsteht, enthält Kompromisse. Beim MVP ist das sogar eine sinnvolle Strategie: Wir prüfen eine Geschäftshypothese, also verzichten wir auf einen Teil der Tests, vereinfachen die Codestruktur und lassen Logik bewusst dort, wo sie am Ende nicht stehen sollte. Solange die Entscheidung bewusst getroffen und festgehalten wird, ist alles in Ordnung. Schlimmer wird es, wenn die Abkürzungen aufhören, vorübergehend zu sein, und sich niemand mehr daran erinnert, dass man sie überhaupt genommen hat.
Die Symptome sind beim ersten Blick in den Code mit bloßem Auge zu erkennen. Die gesamte Geschäftslogik in die Controller gestopft. Derselbe Abschnitt an fünf Stellen kopiert, mit kleinen Abweichungen. Null automatische Tests, null Deployment-Dokumentation. Das Ergebnis ist immer dasselbe: Jede weitere Änderung dauert länger als die vorherige, weil die Entwicklerin oder der Entwickler sich erst im Kopf wieder erarbeiten muss, wie das System arbeitet, und danach manuell prüfen muss, ob nichts kaputtgegangen ist. Der Kunde sieht ausschließlich steigende Preise für einfache Dinge und ärgert sich zu Recht.
Ein eigenes Thema sind veraltete Abhängigkeiten. Vom Framework erscheinen neue Versionen, Bibliotheken bekommen Korrekturen, die Laufzeitumgebung erreicht das Ende des Supports. Eine laufend durchgeführte Migration, Version für Version, sind meist ein paar Stunden Arbeit und ein kurzer Test. Dieselbe Migration um drei Jahre verschoben? Ein Sprung über mehrere Releases auf einmal, rückwärtsinkompatible Änderungen und Wochen an Teamarbeit, weil die Hälfte der genutzten Pakete inzwischen verschwunden ist oder den Eigentümer gewechselt hat.
Der häufigste Fehler sieht so aus: Updates werden aufgeschoben, bis etwas nicht mehr funktioniert. Plötzlich lässt sich keine Korrektur mehr ausliefern, weil der Hoster die alte Version der Umgebung abgeschaltet hat. Oder es taucht eine öffentlich beschriebene Schwachstelle in einer Bibliothek auf, die seit dem Start niemand angefasst hat. Und dann geschieht unter Druck und im Notfallmodus die Arbeit, die man auf ruhige Quartale hätte verteilen können. Deshalb lohnt es sich, bei der Entwicklung von Individualsoftware gleich zu klären, wer in welchem Rhythmus die Versionen der Abhängigkeiten im Blick behält.
Tipp: Reservieren Sie einen festen, wiederkehrenden Slot für Updates – ein paar Stunden im Monat oder einen Tag im Quartal. Regelmäßige kleine Schritte kosten einen Bruchteil dessen, was eine einzige große Migration kostet, die erst dann gemacht wird, wenn es keinen Ausweg mehr gibt.
Sicherheit und Compliance erfordern ständige Arbeit, kein einmaliges Audit
Ein Sicherheitsaudit vor dem Start ist gute Praxis, wird aber mitunter wie ein unbefristet gültiges Zertifikat behandelt. Dabei existierte der größte Teil der Schwachstellen, die die Anwendung treffen werden, zum Zeitpunkt der Einführung noch gar nicht oder war nicht öffentlich bekannt. Jemand hat sie später in einer Bibliothek entdeckt, die das System nutzt, hat sie beschrieben, eine Korrektur veröffentlicht, und damit begann der Wettlauf gegen die Zeit. Ein Bericht von vor einem Jahr beschreibt den Zustand von vor einem Jahr. Mehr nicht.
Sicherheit zu erhalten ist eine Reihe wiederkehrender Tätigkeiten, die im Kalender stehen. API-Schlüssel und Integrationstoken müssen rotiert werden, denn mit der Zeit landen sie an zu vielen Stellen: in Dokumentationen, Nachrichten, Konfigurationen auf den Laptops ehemaliger Mitarbeitender. Berechtigungen im Panel brauchen eine regelmäßige Überprüfung, denn Unternehmen wachsen und Menschen wechseln ihre Rollen, während das Administratorkonto ihnen noch lange erhalten bleibt, nachdem es nicht mehr nötig ist. Zertifikate laufen im unpassendsten Moment ab, meist am Wochenende, ihre Erneuerung sollte also automatisiert und durch einen Alarm überwacht sein.
Zu den Sicherungskopien gesondert, denn das ist ein Bereich voller Illusionen. Allein die Tatsache, dass ein Backup läuft und Platz auf der Festplatte belegt, sagt überhaupt nichts über seine Brauchbarkeit aus. Wert hat erst eine Kopie, aus der sich tatsächlich ein funktionierendes System wiederherstellen ließ – in vernünftiger Zeit, auf einer sauberen Umgebung, mit vollständigen Daten. Ein Wiederherstellungstest einmal im Quartal macht aus einer theoretischen Absicherung eine reale. Ohne ihn findet der erste Versuch der Datenwiederherstellung während einer Störung statt, also unter den denkbar schlechtesten Bedingungen.
Dazu kommt die Compliance-Ebene. Schutz personenbezogener Daten, Aufbewahrungsregeln, Protokollierung der Zugriffe auf sensible Informationen, die Möglichkeit zu dokumentieren, wer wann auf Kundendaten zugegriffen hat. Das erfordert laufende Aufmerksamkeit und nicht das Abhaken eines Punktes auf einer Liste vor dem Start. Vorschriften ändern sich, die Prozesse im Unternehmen ebenfalls, und die Anwendung muss ihnen folgen. Diese Ebene zu vernachlässigen kostet unvergleichlich mehr als sie systematisch im Auge zu behalten.
Integrationen und APIs: die häufigste Quelle ungeplanter Arbeit
Wenn man einen Bereich benennen müsste, der bei Vertragsunterzeichnung die meiste unvorhergesehene Arbeit erzeugt, wären es die Integrationen. Eine Anwendung lebt selten isoliert. Sie spricht mit dem Zahlungs-Gateway, dem Lagersystem, der Buchhaltungssoftware, dem Kurierdienst, dem CRM, dem Werkzeug für den E-Mail-Versand. Jede dieser Verbindungen ist eine Abhängigkeit von Entscheidungen, die außerhalb des Projekts getroffen werden, von Menschen, die von der Existenz unseres Systems keine Ahnung haben.
Anbieter externer APIs tun genau das, was man von wachsenden Unternehmen erwarten kann: Sie veröffentlichen neue Versionen, ziehen alte Endpunkte zurück, ändern das Antwortformat, führen Anfragelimits ein oder erhöhen die Anforderungen an die Authentifizierung. Meist kündigen sie das im Voraus an, in einer Mitteilung im Entwicklerblog oder per E-Mail an die technische Adresse, die bei der Registrierung angegeben wurde. Und diese Adresse ist manchmal ein Postfach, in das niemand hineinschaut. Die Information kommt also erst dann an, wenn die Integration nicht mehr funktioniert.
Die internen Systeme des Kunden verhalten sich ähnlich. Das ERP bekommt ein Update vom Hersteller, die Lagersoftware ändert die Exportstruktur, die Buchhaltung wechselt auf eine neue Version, und plötzlich hat die Datei, die wir seit zwei Jahren parsen, anders benannte Spalten. Niemand hat jemanden vorgewarnt, weil diese Abteilungen im Unternehmen keinen Grund haben, miteinander über Datenformate zu sprechen.
Eine frische Variante desselben Problems sind KI-Modelle. Anbieter ziehen ältere Versionen zurück, ersetzen sie durch neuere mit anderer Antwortcharakteristik und ändern die Abrechnungsweise. Ein auf ein Modell abgestimmter Prompt kann nach dem Austausch Ergebnisse in einem anderen Format liefern, was bei automatischer Verarbeitung der Antworten den gesamten Prozess umwirft. Aus diesem Grund erfordern KI-basierte Anwendungen ein eingeplantes Budget für regelmäßige Prompt-Tests und den Austausch von Modellen.
Die architektonische Entscheidung, die diese Kosten real senkt, ist verblüffend einfach: Streuen Sie die Aufrufe einer externen API nicht über den gesamten Code. Eine Zwischenschicht, ein Punkt, an dem wir das Format des Anbieters in unser internes Modell übersetzen. Dann bedeutet eine Änderung auf der anderen Seite eine Korrektur in einer Datei und keine Archäologie in zwanzig.
Tipp: Abonnieren Sie die Änderungsmitteilungen jedes Anbieters und leiten Sie sie an ein Postfach, das jemand wirklich liest. Eine Integration ist keine mit der Abnahme fertiggestellte Funktion, sondern ein Element, das während der gesamten Lebensdauer des Systems beobachtet werden muss.
Skalierung und Daten, also die Kosten, die mit dem Erfolg wachsen
In der Wartung steckt ein Paradox: Je besser das Geschäft läuft, desto mehr technische Arbeit erfordert die Anwendung. Eine Abfrage, die bei tausend Datensätzen sofort ausgeführt wurde, kann bei einer Million die Oberfläche blockieren. Nichts ist kaputtgegangen, niemand hat einen Fehler gemacht. Es hat sich schlicht die Charakteristik der Daten geändert und damit die Art, wie die Datenbank ihren Ausführungsplan wählt. Ein Bericht, der bisher unbemerkt im Hintergrund erzeugt wurde, wird plötzlich zum häufigsten Thema der Tickets.
Die Datenbank braucht also laufende Pflege. Indizes, die auf reale Nutzungsmuster abgestimmt sind und nicht auf Vorstellungen aus der Entwurfsphase. Archivierung historischer Daten, damit die operativen Tabellen nicht endlos mit Bestellungen von vor fünf Jahren anschwellen. Aufräumen dessen, was sich angesammelt hat: verwaiste Datensätze, Duplikate aus fehlgeschlagenen Importen, Logs ohne jede Aufbewahrungsrichtlinie. Diese Arbeit fügt keine einzige für die Nutzer sichtbare Funktion hinzu und entscheidet trotzdem darüber, ob das System nutzbar bleibt.
Ein eigenes Thema: zeitlich schwankender Traffic. Ein Shop vor den Feiertagen, ein Buchungssystem in der Saison, eine Schulungsplattform zu Jahresbeginn – die Last kann sich innerhalb einer Woche um ein Vielfaches ändern. Das ganze Jahr über Rechenleistung für die Spitze vorzuhalten heißt, die meisten Monate für Luft zu zahlen. Vernünftiger ist eine Architektur, die es erlaubt, für die Spitze hochzuskalieren und danach wieder herunterzufahren, auch wenn das frühere Entwurfsentscheidungen voraussetzt. Nicht jede Anwendung lässt sich ohne Umbauten so betreiben.
Zusammengehalten wird das alles vom Monitoring. Erfassung von Metriken, Alarme für Antwortzeiten, freien Speicherplatz, Aufgabenwarteschlangen, Fehler in den Logs. Es wirkt überflüssig, solange alles funktioniert. Der Unterschied ist aber grundlegend: Entweder das technische Team fängt das Problem in dem Moment ab, in dem es erst entsteht, oder es erfährt davon von einem verärgerten Kunden, wenn der Prozess bereits seit einer Stunde stillsteht. Die zweite Variante kostet um ein Vielfaches mehr, den Ruf mitgerechnet.
Wie man ein Wartungsbudget sinnvoll plant
Ein guter Wartungsvertrag beginnt mit Präzision in der Beschreibung des Umfangs. Die meisten Missverständnisse entstehen daraus, dass beide Seiten das Wort “Support” unterschiedlich verstehen: der Kunde als Bereitschaft für alles, der Dienstleister als Reaktion auf kritische Störungen. Legen Sie also schwarz auf weiß fest, wie hoch die Reaktions- und die Behebungszeit ist, in welchen Stunden sie gilt, was ein vom Vertrag abgedeckter Fehler ist und was eine separat abgerechnete neue Funktionalität.
Aus der Praxis: Das sauberste Modell ist die Trennung von drei Finanzierungssträngen. Technische Wartung, also Infrastruktur, Updates, Backups und Monitoring – ein fester Betrag, für beide Seiten planbar. Fehlerbehebung, also das Beseitigen von Mängeln an dem, was abgenommen wurde. Und Weiterentwicklung, also ein Stundenkontingent für neue Funktionen und Änderungen aus dem laufenden Bedarf. Wenn alles aus einem Topf kommt, gewinnt die Weiterentwicklung immer gegen die Updates, denn sie ist sofort sichtbar, während die Folgen vernachlässigter Wartung erst nach einem Jahr auftauchen.
Die zweite Sache, die Sie sich zu Beginn sichern sollten, ist Unabhängigkeit. Der Zugang zum Code-Repository, zu den Hosting-Konten, zu den Domains und zur Deployment-Dokumentation sollte vom ersten Tag an auf Kundenseite liegen. Nicht, weil Sie einen Wechsel des Dienstleisters planen. Sondern weil jeder Anbieter verschwinden kann und das System länger bestehen soll als die Geschäftsbeziehung. Ein Unternehmen, das gegen eine solche Regelung nichts einzuwenden hat, signalisiert, dass es die Zusammenarbeit durch Qualität und nicht durch Blockaden halten will.
Bevor Sie den Vertrag unterschreiben, stellen Sie einige Fragen:
- Was genau umfasst die monatliche Pauschale und was wird zusätzlich abgerechnet?
- Wie hoch ist die Reaktionszeit bei einer kritischen Störung und in welchen Stunden gilt sie?
- Wem gehören der Code, die Hosting-Konten und die Domains?
- Wie sieht der Prozess der Aktualisierung von Abhängigkeiten aus und wer zahlt dafür?
- Werden die Sicherungskopien durch Wiederherstellung getestet und wie oft?
- Was passiert mit dem System, wenn wir die Zusammenarbeit beenden?
Tipp: Rechnen Sie die Wartungskosten noch vor dem Start durch, in der Phase der Technologieauswahl. Ein exotischer Stack ist manchmal günstiger im Aufbau und teurer über die nächsten fünf Jahre, weil sich schwerer Menschen finden, die ihn verstehen.
Fazit: Die Wartung entscheidet, ob sich die Anwendung rechnet
Eine Anwendung, die ohne Betreuung bleibt, verliert schneller an Wert, als sie die Kosten ihrer Entstehung zurückzahlen kann. Das klingt hart, beschreibt aber einen Mechanismus, der sich in Projekten unabhängig von Branche und Größe wiederholt. Das System funktioniert, solange sich das Umfeld nicht ändert, und danach beginnt das Abrutschen: kleine Störungen, langsamerer Betrieb, eine gerissene Integration, eine Funktion, die sich ohne das Neuschreiben des halben Codes nicht mehr aktualisieren lässt. Jede dieser Etappen verschlingt Budget, das niemand vorher eingeplant hat, weil in der ursprünglichen Amortisationsrechnung ausschließlich die Umsetzungskosten standen.
Deshalb sollte ein ehrliches Gespräch über die Wartungskosten ganz am Anfang stattfinden, noch bei der Auswahl der Technologie und des MVP-Umfangs. Ein Kunde, der weiß, wie viel Infrastruktur, technische Betreuung und ein Stundenkontingent für die Weiterentwicklung monatlich kosten werden, entscheidet mit dem vollen Bild vor Augen. Das schützt sein Budget vor Überraschungen und die Beziehung zum Dienstleister vor dem schlimmsten Szenario, in dem jede notwendige technische Arbeit zum Streitgegenstand wird. Planbarkeit zahlt sich für beide Seiten aus.
Bei Web Systems gehen wir das aus der Perspektive eines Teams an, das seit 2006 Web- und Mobile-Anwendungen, B2B-Systeme, API-Integrationen, Automatisierungen, E-Commerce sowie KI-basierte Lösungen entwirft und umsetzt. In dieser Zeit haben wir genügend Systeme von anderen Dienstleistern übernommen, um zu wissen, wo sich die Probleme sammeln: in ausgelassenen Updates, in über den Code verstreuten Aufrufen externer APIs, in ungetesteten Sicherungskopien und im Fehlen von Dokumentation. Deshalb planen wir die Architektur mit Blick darauf, was nach dem Start passieren wird, und nicht ausschließlich auf den Abnahmetermin.
Planen Sie eine neue Anwendung, ein MVP, eine Systemintegration, die Automatisierung von Prozessen, die Einführung von KI oder die Modernisierung einer Lösung, die dem Unternehmen nicht mehr folgen kann? Schreiben Sie uns. Wir rechnen Ihnen gern nicht nur die Kosten des Aufbaus aus, sondern auch die realen Wartungskosten der kommenden Jahre, damit Sie Ihre Entscheidung auf Grundlage der vollen Summe treffen können und nicht nur ihres ersten Teils.
