Viele Unternehmen planen ein Softwareprojekt bis zum Launch – und behandeln den Go-live als Ziellinie. Tatsächlich beginnt danach die längste und in Summe teuerste Phase. Über die gesamte Lebensdauer macht der Betrieb 50 bis 80 % der Gesamtkosten einer Software aus. Die Entwicklung passiert einmal, die Wartung läuft jahrelang weiter.
Deshalb suchen Unternehmen nach „Software-Wartung", „Software weiterentwickeln lassen" oder „Wartungsvertrag Software". Gemeint ist selten nur technischer Support. Es geht darum, eine Web-App, Plattform, mobile App oder ein internes Tool dauerhaft sicher, stabil und sinnvoll erweiterbar zu halten – mit einem klaren Budget statt mit Notfällen.
Warum der Betrieb teurer ist als der Launch
Software ist kein abgeschlossenes Bauwerk, sondern läuft in einer Umgebung, die sich ständig verändert. Abhängigkeiten bekommen Sicherheitsupdates, Browser ändern ihr Verhalten, APIs verschieben Limits, Nutzer finden Randfälle und interne Prozesse entwickeln sich weiter. Genau deshalb verschiebt sich der Kostenschwerpunkt vom Bau zum Betrieb.
Wenn nach dem Launch niemand verantwortlich ist, entstehen vorhersehbare Probleme: Fehler werden erst entdeckt, wenn Kunden sie melden, Updates werden aufgeschoben und später riskant, kleine Bugs sammeln sich zu technischen Schulden, und niemand kennt mehr die ursprünglichen Architekturentscheidungen. Das ist nicht nur lästig, sondern teuer: Laut einer ITIC-Erhebung kostet eine einzige Stunde Ausfall bei über 90 % der befragten größeren Organisationen mehr als 300.000 $. Eine gute Software-Agentur plant deshalb nicht nur die erste Version, sondern den Betrieb danach.
Was professionelle Wartung umfasst
Wartung hält das System gesund – Weiterentwicklung erweitert seinen Nutzen. Diese Trennung ist die wichtigste Budgetentscheidung, denn sonst konkurrieren Pflicht und Wachstum um dasselbe Geld. Für eine Marketing-Website reicht oft ein schlankes Modell; eine B2B-Plattform mit Login, Rollen, Dateien und Schnittstellen braucht mehr Verantwortung.
Typische Wartungsleistungen sind:
- Monitoring von Fehlern, Verfügbarkeit und Performance
- Sicherheitsupdates für Frameworks, Libraries und Infrastruktur
- Bugfixing und technische Fehleranalyse
- Dependency-Updates und Kompatibilitätsprüfungen
- Backups und regelmäßige Wiederherstellungstests
- Deployment-Betreuung sowie Prüfung von Logs und Warnmeldungen
- API- und Integrationssupport und Dokumentation von Änderungen
- technische Beratung für die Roadmap
Ein Weiterentwicklungs-Retainer kommt darüber hinaus: Produktplanung, UX/UI-Verbesserungen, neue Funktionen, Refactorings, Tests und QA, regelmäßige Releases und Roadmap-Abstimmung. Für viele Unternehmen ist die Kombination sinnvoll – ein Grundbudget für Wartung plus ein flexibles Budget für priorisierte Weiterentwicklung.
Was Software-Wartung kostet
Die belastbarste Planungsgröße ist nicht ein Stundensatz, sondern ein Anteil an den Entwicklungskosten. Die seit Jahrzehnten stabile Faustregel liegt bei 15 bis 25 % der ursprünglichen Entwicklungskosten pro Jahr – bei sauberer, gut dokumentierter Software eher am unteren Rand, bei Legacy-Code mit hohen technischen Schulden eher bei 30 bis 40 %. Übersetzt in monatliche Modelle ergibt das folgende Korridore:
| Modell | Geeignet für | Typischer Korridor |
|---|---|---|
| Basis-Wartung | Website, kleine Web-App, wenige Änderungen | 500–2.000 € pro Monat |
| Produkt-Wartung | Kundenportal, interne App, regelmäßige Updates | 2.000–6.000 € pro Monat |
| Produktteam-Retainer | laufende Roadmap, UX, Entwicklung, QA, Betrieb | 6.000–20.000 € pro Monat |
| Kritischer Betrieb mit SLA | hohe Verfügbarkeit, mehrere Systeme, feste Reaktionszeiten | individuell, häufig ab 10.000 € |
Diese Zahlen sind Planungsgrößen, keine Preisliste. Ein einfaches Content-Projekt ist günstiger als eine Plattform mit Rollen, Zahlungslogik, ERP-Schnittstelle und sensiblen Daten. Wer von Anfang an schlecht baut, zahlt hier doppelt – warum das so ist, zeigt Warum billige Software teuer wird.
Sicherheitsupdates: warum Aufschieben teuer wird
Moderne Software besteht zu großen Teilen aus fremdem Code – und der altert. Frameworks, Pakete, APIs und Cloud-Dienste sparen Entwicklungszeit, müssen aber gepflegt werden. Das Tempo ist hoch: Allein 2025 wurden über 40.000 neue Sicherheitslücken (CVEs) veröffentlicht – ein Rekordjahr und rund 127 pro Tag.
Gleichzeitig fallen Laufzeiten aus dem Support: Node.js 18 ist seit dem 30. April 2025 End-of-Life, PHP 8.1 seit Ende 2025. Wer auf solchen Versionen bleibt, bekommt keine Sicherheitsfixes mehr. Gute Wartung prüft deshalb regelmäßig: Gibt es kritische Sicherheitslücken? Sind Frameworks und Libraries noch unterstützt? Funktionieren Builds und Tests nach Updates? Müssen Secrets, API-Keys oder Zertifikate rotiert werden? Hinzu kommt seit dem 28. Juni 2025 das Barrierefreiheitsstärkungsgesetz (BFSG), das viele Web-Apps und Shops dauerhaft barrierefrei halten müssen – Details in unserer BFSG-Checkliste. Wer Updates jahrelang ignoriert, spart kurzfristig und zahlt später mit einer teuren Migration; bei Legacy-Software ist das einer der häufigsten Kostentreiber.
Vom Betrieb zur Roadmap: der Wartungskreislauf
Wartung funktioniert als Kreislauf, nicht als Stapel einzelner Tickets. Ohne Monitoring ist Betrieb Blindflug: Ein System kann online sein und trotzdem fachlich versagen – E-Mails gehen nicht raus, Zahlungen hängen, ein API-Import bricht leise ab. Sinnvolle Signale sind Uptime, Backend- und JavaScript-Fehler, fehlgeschlagene Jobs, API-Limits, langsame Datenbankabfragen und Core Web Vitals. Aus diesen Signalen wird priorisiert, umgesetzt und released – und der nächste Release liefert wieder Daten.
Die Priorisierung gehört in ein SLA (Service Level Agreement). Nicht jede Anwendung braucht strenge Reaktionszeiten – ein internes Tool mit wenigen Nutzern hat andere Anforderungen als ein Buchungsportal:
| Priorität | Beispiel | Reaktion |
|---|---|---|
| Kritisch | System nicht erreichbar, Login ausgefallen, Datenverlust droht | sofort oder innerhalb weniger Stunden |
| Hoch | Kernfunktion gestört, viele Nutzer betroffen | am selben Arbeitstag |
| Mittel | Fehler mit Workaround, einzelne Nutzer betroffen | innerhalb weniger Werktage |
| Niedrig | kosmetische Fehler, kleine Verbesserungen | nach Priorisierung |
Wichtig ist, Reaktionszeit nicht mit Lösungszeit zu verwechseln. Ein Team kann schnell reagieren, aber die vollständige Behebung hängt von Ursache, Zugriffen, Drittanbietern und Testaufwand ab. Die beste Roadmap entsteht dann auf drei Ebenen: Pflicht (Sicherheit, Bugfixes, Stabilität, Datenschutz), Verbesserung (UX, Performance, Automatisierung) und Wachstum (neue Funktionen, Integrationen).
Technische Schulden sichtbar machen
Technische Schulden sind kein Zeichen schlechter Arbeit, sondern eine Bilanzposition, die man kennen muss. Sie entstehen durch bewusste MVP-Entscheidungen, Zeitdruck oder neue Anforderungen. Laut McKinsey machen technische Schulden rund 40 % der IT-Bilanz aus, und Unternehmen zahlen auf neue Projekte oft 10 bis 20 % „Zinsen", um Altlasten mitzuschleppen.
Typische technische Schulden sind fehlende Tests für kritische Prozesse, zu enge Kopplung zwischen Frontend und Backend, schlecht dokumentierte Schnittstellen, manuelle Deployments, unklare Berechtigungslogik und Datenmodelle, die nicht mehr zum Produkt passen. Nicht jede Schuld muss sofort bezahlt werden – aber sie sollte sichtbar sein. Gute Wartung führt eine technische Roadmap, damit Refactorings geplant statt als Notfall erledigt werden. Der beste Einstieg in eine bestehende Anwendung ist ein Software-Audit, das Risiken erst versteht, bevor etwas umgebaut wird.
Wartungsvertrag oder Weiterentwicklungs-Retainer?
Beide Modelle beantworten verschiedene Fragen – und die meisten Produkte brauchen eine Mischung. Ein Wartungsvertrag klärt: Wer hält das System stabil? Er enthält feste Reaktionszeiten, definierte Supportkanäle, Updates, Sicherheitsprüfungen, Fehleranalyse und Monitoring. Ein Weiterentwicklungs-Retainer klärt: Wer verbessert das Produkt jeden Monat? Er ergänzt Produktplanung, neue Funktionen, Refactorings, QA und regelmäßige Releases.
Für kleinere Systeme reicht oft ein schlankes Wartungsmodell. Für wachsende Produkte ist ein eingespieltes Produktteam sinnvoller als einzelne Ad-hoc-Tickets, weil Wartung mehrere Disziplinen berührt: Backend, Frontend, Infrastruktur, Security, UX, QA und Produktpriorisierung. Eine externe Agentur lohnt sich vor allem, wenn intern nicht genug Kapazität oder technische Breite vorhanden ist oder eine bestehende Anwendung übernommen werden soll.
Nächste Schritte
Drei Fragen klären dein Betriebsmodell schneller als jede Leistungsliste:
- Kritikalität: Was darf passieren, wenn das System eine Stunde ausfällt – und welche Reaktionszeiten brauchst du wirklich?
- Verantwortung: Wer priorisiert Bugs und neue Anforderungen, und gibt es ein festes monatliches Budget für Weiterentwicklung?
- Zustand: Sind Monitoring, Backups, Updates und technische Schulden bekannt – oder braucht es zuerst ein Audit?
Unsicher, welches Modell zu deinem Produkt passt? Wir übernehmen Betrieb und Weiterentwicklung regelmäßig in Projekten – pragmatisch und mit Blick auf Roadmap und Budget. Sieh dir unsere Web-App-Entwicklung an oder buche direkt ein Erstgespräch.
