Was Software-Wartung nach dem Launch kostet: Ein DACH-SaaS-Benchmark
Der Launch beendet das Software-Budget nicht. Er verändert seine Form. Vor dem Launch kaufst du Discovery, Implementierung, QA und Deployment. Nach dem Launch kaufst du Kontinuität: Bugfixes, Dependency-Upgrades, Cloud und Observability, Security, Compliance, Support, Produktiteration und Notfallarbeit.
Dieser Artikel ist bewusst getrennt von unserem Softwareentwicklungs-Guide. Dort geht es um Build-Kosten. Hier geht es um Post-Launch-Kosten: Was kostet Software-Wartung pro Jahr, nachdem ein SaaS-Produkt live ist?
Brauchst du ein verteidigbares Wartungsbudget?
Operating Model planenDie Benchmark-Antwort
Für ein DACH-SaaS-Produkt solltest du grob 18-30 % der ursprünglichen Build-Kosten pro Jahr einplanen, wenn das Produkt weiterentwickelt wird. Ein ruhiges internes Tool kann näher bei 10-16 % liegen. Ein reguliertes, integrationslastiges oder schnell wachsendes SaaS-Produkt kann 35-60 % erreichen, wenn Compliance, Support, Security und Produktiteration gleichzeitig aktiv sind.
In unserem Richtwert-Benchmark aus 24 DACH-SaaS- und SaaS-nahen Produkten, die zwischen 2023 und Mitte 2026 gewartet wurden, lag der Median bei 24 % der ursprünglichen Build-Kosten in Jahr eins, 21 % in Jahr zwei und 26 % in Jahr drei. Der Anstieg im dritten Jahr kam nicht durch magischen Software-Zerfall. Auslöser waren Major-Versionen von Frameworks, Cloud-Wachstum, angesammelte Produktwünsche, Compliance-Nachweise, Security Findings und Integrationen, die geschäftskritisch geworden waren.
| Post-Launch-Jahr | Median | Mittlere 50 % | Bei EUR 150k Build | Typische Treiber |
|---|---|---|---|---|
| Jahr 1 | 24 % der Build-Kosten | 16-34 % | EUR 36k | Launch-Defekte, Support, Observability, Security-Basics, erste Produktiteration. |
| Jahr 2 | 21 % der Build-Kosten | 13-31 % | EUR 31,5k | Weniger Launch-Bugs, mehr Kundensupport, Dependency-Updates, gemessene Produktarbeit. |
| Jahr 3 | 26 % der Build-Kosten | 15-40 % | EUR 39k | Major-Upgrades, Compliance-Belege, Skalierungskosten, Integrationsdrift, Architekturaufräumen. |
Was zählt als Software-Wartung?
ISO/IEC-Wartungssprache unterscheidet korrektive, adaptive, perfektive und präventive Wartung. In echten SaaS-Budgets heißt das: korrektive Arbeit behebt Bugs, adaptive Arbeit hält das Produkt trotz Browsern, APIs, Geräten und Gesetzen nutzbar, perfektive Arbeit verbessert Produkt und Wartbarkeit, präventive Arbeit reduziert künftiges Risiko. Ein Ticket berührt oft mehrere Kategorien.
| Budgetzeile | Was enthalten ist | Was nicht enthalten ist |
|---|---|---|
| Bugfixes | Produktionsfehler, Regressionen, Daten-Edge-Cases, kaputte Workflows. | Große Features, die als Bug etikettiert werden. |
| Dependencies und Framework-Upgrades | Packages, Runtime-Versionen, Datenbank-Clients, SDKs, Breaking Framework Migrations. | Rewrite aus Geschmack. |
| Cloud und Observability | Hosting, Logs, Metriken, Traces, Alerts, Backups, Uptime Checks, Kostenreviews. | Cloud-Ausgaben ohne Owner. |
| Security | Vulnerability-Fixes, Secrets Rotation, Access Reviews, SAST/SCA, Pentest-Fixes. | Ein jährlicher Checkbox-Termin. |
| Compliance | DSGVO-Anfragen, DPAs, Audit Evidence, Retention, AI-Act/CRA/NIS2-Readiness wo relevant. | Reine Rechtsberatung. |
| Support | Technische Triage, User-Probleme, Admin-Anfragen, Incident-Kommunikation, Handover-Doku. | Customer-Success-Strategie. |
| Produktiteration | Kleine Verbesserungen, UX-Fixes, Reports, Workflow-Polish, Conversion-Verbesserungen. | Eine neue Produktlinie. |
| Notfallarbeit | Outages, Provider Incidents, dringende Security-Fixes, Datenreparatur, Rollback. | Roadmap-Druck mit Urgent-Label. |
Jahr eins, zwei und drei im Detail
| Position | Jahr 1 | Jahr 2 | Jahr 3 | Warum es sich bewegt |
|---|---|---|---|---|
| Bugfixes | 4,0 % | 2,5 % | 3,0 % | Launch-Bugs sinken, ältere Integrationen erzeugen neue Edge Cases. |
| Dependencies und Framework-Upgrades | 2,0 % | 3,0 % | 5,0 % | Aufgeschobene Minor-Updates werden Major-Version-Arbeit. |
| Cloud und Observability | 4,0 % | 4,0 % | 5,0 % | Nutzung, Logs, Retention und Monitoring-Tiefe wachsen. |
| Security | 3,0 % | 2,5 % | 3,0 % | Jahr eins setzt Basics, später patchst du Supply Chain und Access Drift. |
| Compliance | 2,0 % | 2,0 % | 3,0 % | Kunden und Regulatorik verlangen mit Reife mehr Nachweise. |
| Support | 3,0 % | 3,0 % | 4,0 % | Mehr Nutzer erzeugen mehr Triage, Admin und Dokumentation. |
| Produktiteration | 5,0 % | 3,0 % | 2,0 % | Frühes Feedback ist dicht; spätere Iteration wird oft eigenes Roadmap-Budget. |
| Notfallarbeit | 1,0 % | 1,0 % | 1,0 % | Eine Reserve verhindert Beschaffungspanik im Incident. |
| Summe | 24,0 % | 21,0 % | 26,0 % | Der Rechner passt die Annahmen an. |
Interaktiver Wartungskosten-Rechner
Der Rechner startet mit dem Benchmark und passt nach Produkttyp, Compliance-Druck, Nutzung, Supportlast und Technical Debt an.
Warum Dependencies eine echte Budgetzeile sind
Moderne SaaS-Produkte bestehen aus Custom Code plus Supply Chain: Frameworks, Packages, SDKs, Build Tools, Container Images, Cloud Services und APIs. Der Long Tail kostet Geld. Sonatype-Daten zu Log4j, berichtet von ITPro, zeigen, dass auch vier Jahre nach Log4Shell noch ein relevanter Anteil der Downloads verwundbar war, obwohl Fixes verfügbar waren. Die Lehre: Verwundbare Dependencies bleiben oft liegen, weil niemand Wartung besitzt.
Cloud, Security, Compliance und Support
Cloud und Observability sind nach Launch keine Extras. Traffic, Logs, Traces, Metriken, Storage, Backups, Queues, E-Mail, Suche, KI-APIs und Monitoring werden wiederkehrende Kostentreiber. Security und Compliance sind ebenfalls Lifecycle-Arbeit: DSGVO gilt jetzt, NIS2, Cyber Resilience Act und EU AI Act erhöhen je nach Produkt und Sektor den Nachweisdruck. Support wiederum zeigt dir, wo das Produkt unklar, fragil oder schlecht dokumentiert ist.
Produktiteration ohne Kannibalisierung
Ein Build-Kosten-Guide beantwortet: Was kostet es, das Produkt zu bauen? Ein Wartungs-Benchmark beantwortet: Was kostet es, das Produkt nach dem Launch nützlich zu halten? Kleine Workflow-Verbesserungen, UX-Fixes und Reports gehören in Wartung. Neue Module, neue Personas, neue Preismodelle oder Mobile neben Web gehören meist in ein eigenes Roadmap-Budget.
Der kommerzielle Pfad ist klar: Custom Software Development für den Build, Software-QA für Regression und Vertrauen, und Fractional CTO, wenn dein Produkt Betriebsrhythmus, Architekturentscheidungen und Vendor Accountability braucht.
Quellen und Caveat
Der Benchmark basiert auf Wavect-Beobachtungen aus 24 anonymisierten DACH-SaaS- und SaaS-nahen Produkten plus externer Evidenz zu Wartungskategorien, Software-Supply-Chain-Risiken und EU-Regulierungsdruck. Richtwert, keine repräsentative Marktstudie. Für Wartungskategorien siehe ISO/IEC/IEEE 14764 und SWEBOK. Für Supply-Chain-Risiko siehe ITPro zu Sonatype/Log4j und die SLSA-Analyse auf arXiv. Für EU-Pflichten prüfe DSGVO, NIS2, Cyber Resilience Act und EU AI Act. Cloud- und Observability-Preise vor Budgetierung live nachprüfen, etwa AWS CloudWatch, Datadog und Sentry.
Fazit
Ein gesundes Wartungsbudget ist kein diffuser Retainer. Es ist ein Post-Launch-Operating-Model mit benannten Zeilen: Bugs, Dependencies, Cloud, Observability, Security, Compliance, Support, Produktiteration und Notfälle. Für ein normales, weiterentwickeltes SaaS-Produkt sind 18-30 % der ursprünglichen Build-Kosten pro Jahr ein verteidigbarer Startwert.
Trenne Build-Budget, Wartungsbudget und Roadmap-Budget. Wenn du sie mischst, entsteht die klassische Überraschung nach dem Launch: Alle dachten, das Produkt sei fertig, während die Software längst ein lebendes System mit Nutzern, Abhängigkeiten, Gesetzen und Incidents geworden ist.
Willst du daraus deinen Wartungsplan machen?
Mit Wavect sprechenProdukt bauen, nicht nur Backlog
Wenn dieser Artikel auf eine echte Produktentscheidung einzahlt, hilft Wavect dir beim Scoping, Bauen, Härten oder Führen der Softwarearbeit mit Senior-Founder-Urteil.
Sinnvolle Service-Wege: