Wartung & Weiterentwicklung - was nach dem Launch niemand einplant

Der Launch ist oft der Moment, in dem das Projektbudget als "erledigt" gilt. Tatsächlich beginnt hier ein neuer, dauerhafter Kostenblock, der in vielen Kalkulationen schlicht fehlt: Betrieb, Wartung und Weiterentwicklung.

Warum der Launch nicht das Ende der Kosten ist

Software ist kein Produkt, das nach Fertigstellung unverändert bleibt. Betriebssysteme, Browser, Bibliotheken und APIs von Drittanbietern ändern sich laufend - eine Software, die nicht gepflegt wird, verliert innerhalb weniger Jahre an Sicherheit und Kompatibilität. Wer die Software nach Launch sich selbst überlässt, riskiert Sicherheitslücken und irgendwann eine kostspielige Neuentwicklung, statt kontinuierlicher, planbarer Pflege.

Die drei Kostenblöcke nach dem Go-Live

Hosting und Infrastruktur: laufende Kosten für Server, Datenbank, CDN und Monitoring - meist überschaubar, aber dauerhaft. Für eine typische KMU-Webanwendung liegen diese Kosten oft im niedrigen dreistelligen Bereich pro Monat, können bei wachsender Nutzerzahl aber deutlich steigen.

Sicherheits-Patches und Abhängigkeiten: Bibliotheken und Frameworks brauchen regelmäßige Updates, um bekannte Schwachstellen zu schließen. Das ist keine Feature-Arbeit, sondern reine Instandhaltung - und sollte separat budgetiert werden, unabhängig davon, ob in einem Monat neue Funktionen entstehen oder nicht.

Feature-Wünsche und Weiterentwicklung: Nach dem Launch entstehen fast immer neue Anforderungen aus dem echten Nutzungsverhalten. Diese Arbeit ist planbar, wenn du sie von Anfang an als eigenen Budgetposten einkalkulierst statt sie überrascht nachzuverhandeln.

Wie viel Aufwand ist realistisch?

Als grobe Orientierung für eine mittelgroße SaaS- oder Businessanwendung nach dem Launch:

Ruhige Phase (Software läuft stabil, wenig neue Nutzer): oft 1-3 Personentage pro Monat für Monitoring, kleinere Patches und Abhängigkeits-Updates.
Aktive Weiterentwicklung (neue Features, wachsende Nutzerzahl): 5-10 Personentage pro Monat sind keine Seltenheit, abhängig davon, wie viele Feature-Wünsche gleichzeitig umgesetzt werden sollen.
Kritische Phase (Migration, Lastspitzen, größere Abhängigkeits-Updates wie ein Framework-Major-Upgrade): kurzfristig deutlich mehr, dafür zeitlich begrenzt.

Diese Zahlen sind branchen- und projektabhängig, helfen aber, ein Angebot realistisch einzuschätzen: Wenn ein Anbieter dauerhaft mit weniger als einem Personentag pro Monat kalkuliert, wird meist entweder an Sicherheits-Updates gespart oder die Zahl später stillschweigend nach oben korrigiert.

Organisationsmodelle: Retainer vs. Ad-hoc vs. eigenes Team

Es gibt im Kern drei Wege, Wartung und Weiterentwicklung zu organisieren:

Wartungspauschale (Retainer). Ein festes monatliches Stundenkontingent, das für Patches, kleinere Anpassungen und Support genutzt wird. Vorteil: planbare Kosten, garantierte Reaktionszeiten, der Anbieter kennt die Codebasis kontinuierlich. Nachteil: du zahlst auch in ruhigen Monaten die volle Pauschale, und ungenutzte Stunden verfallen meist.

Ad-hoc-Beauftragung. Wartung und Fixes werden nach Bedarf beauftragt, ohne festen Vertrag. Vorteil: keine laufenden Fixkosten in ruhigen Phasen. Nachteil: keine garantierten Reaktionszeiten bei einem kritischen Ausfall, und der Entwickler muss sich bei jedem Einsatz neu in den aktuellen Stand einarbeiten - das kostet Zeit und Geld.

Eigenes internes Team. Sinnvoll, sobald der laufende Aufwand konstant hoch ist (z. B. mehr als 15-20 Personentage pro Monat) und die Software geschäftskritisch für den täglichen Betrieb ist. Für die meisten KMU mit einer einzelnen Anwendung lohnt sich das erst ab einer gewissen Größe - vorher ist ein externer Partner meist wirtschaftlicher.

Für die meisten KMU mit einer einzelnen Business- oder SaaS-Anwendung ist eine Wartungspauschale mit einem monatlich verfallenden Stundenkontingent der beste Kompromiss zwischen Planbarkeit und Kosten.

Einen realistischen Wartungsvertrag verhandeln

Ein guter Wartungsvertrag regelt konkret:

Reaktionszeiten: Wie schnell reagiert der Anbieter bei kritischen Fehlern im Live-Betrieb, wie schnell bei kleineren?
Umfang: Sind Sicherheits-Updates inkludiert, oder nur Bugfixing? Wo endet Wartung und wo beginnt kostenpflichtige Weiterentwicklung?
Abrechnungsmodell: Pauschale pro Monat, Stundenkontingent, oder Abruf nach Bedarf? Ein Stundenkontingent, das monatlich verfällt, ist für die meisten KMU planbarer als offene Time-and-Material-Abrechnung.
Laufzeit und Kündigungsfrist: Kannst du den Vertrag wechseln, ohne den Betrieb zu gefährden?
Dokumentation und Übergabe: Wird der Code und die Architektur dokumentiert, sodass ein anderer Anbieter im Ernstfall übernehmen könnte?

Wie viel solltest du einplanen?

Als grobe Orientierung kalkulieren viele Anbieter 15-20% der ursprünglichen Entwicklungskosten pro Jahr für Wartung und kleinere Weiterentwicklung. Bei einem MVP, das 60.000 Euro gekostet hat, wären das also 9.000 bis 12.000 Euro pro Jahr, verteilt auf Hosting, Sicherheits-Updates und kleinere Anpassungen. Das ist keine feste Regel, aber ein guter Ausgangspunkt, um zu prüfen, ob ein Angebot realistisch ist - oder ob der günstige Festpreis am Anfang später durch teure Nachträge kompensiert wird.

Wartung ist kein Ersatz für gute Planung beim MVP

Wie viel Wartungsaufwand nach dem Launch entsteht, wird schon während der Erstentwicklung mitentschieden. Ein MVP, das unter Zeitdruck mit vielen Abkürzungen gebaut wurde, verursacht in der Regel deutlich höhere laufende Kosten als eines, bei dem Architektur und Anforderungen von Anfang an sauber durchdacht waren - selbst wenn beide zum gleichen Festpreis entstanden sind. Wer die Anforderungsklärung vor dem Entwicklungsstart ernst nimmt, reduziert damit nicht nur das Risiko im Projekt selbst, sondern auch die Wartungslast danach.

Typische Fehler bei der Wartungsplanung

Wartung wird erst nach dem ersten Vorfall thematisiert. Viele Unternehmen denken erst über einen Wartungsvertrag nach, wenn bereits ein kritischer Fehler im Live-Betrieb aufgetreten ist. Zu diesem Zeitpunkt fehlt die Verhandlungsposition, die man vor Projektstart noch hätte.

Feature-Wünsche werden mit Bugfixing vermischt. Ohne klare Trennung zwischen "das war schon immer kaputt" und "das ist eine neue Anforderung" entstehen ständig Diskussionen darüber, was im Wartungsvertrag inbegriffen ist und was zusätzlich abgerechnet wird.

Die Dokumentation bleibt beim ursprünglichen Entwicklerteam im Kopf. Wenn nur eine Person weiß, wie ein zentraler Teil des Systems funktioniert, wird jeder Wechsel - ob geplant oder ungeplant - teuer und riskant.

Wann lohnt sich ein Anbieterwechsel?

Ein Wechsel des Wartungspartners lohnt sich meist dann, wenn Reaktionszeiten wiederholt nicht eingehalten werden, wenn Zusatzarbeiten regelmäßig teurer abgerechnet werden als vertraglich vereinbart, oder wenn grundlegende Dokumentation fehlt und du dadurch faktisch an einen einzigen Anbieter gebunden bist. Ein sauber dokumentierter Code und ein klarer Übergabeprozess im Vertrag sind deshalb kein Nice-to-have, sondern eine Absicherung für genau diesen Fall.

Fazit

Wartung und Weiterentwicklung sind kein optionaler Zusatz, sondern ein fester Bestandteil der Gesamtkosten eines Softwareprojekts. Wer das vor dem ersten Vertrag einplant, verhandelt bessere Konditionen - und wird nach dem Launch nicht von der Realität überrascht.

Häufig gestellte Fragen

Welche Kosten entstehen nach dem Launch einer Software?

Drei Kostenblöcke: laufendes Hosting und Infrastruktur, Sicherheits-Patches für Abhängigkeiten und Frameworks, sowie Weiterentwicklung durch neue Feature-Wünsche aus dem echten Nutzungsverhalten. Alle drei sollten separat budgetiert werden.

Was sollte ein Wartungsvertrag regeln?

Ein guter Wartungsvertrag legt Reaktionszeiten bei Fehlern, den genauen Leistungsumfang (Sicherheits-Updates vs. reines Bugfixing), das Abrechnungsmodell sowie Laufzeit, Kündigungsfrist und Dokumentationspflichten fest.

Wie viel Budget sollte ich für Wartung einplanen?

Als grobe Orientierung kalkulieren viele Anbieter 15-20% der ursprünglichen Entwicklungskosten pro Jahr für Wartung und kleinere Weiterentwicklung. Das ist ein guter Richtwert, um Angebote realistisch einzuschätzen.

Wartungspauschale oder Ad-hoc-Beauftragung - was ist besser?

Für die meisten KMU mit einer einzelnen Anwendung ist eine Wartungspauschale mit monatlich verfallendem Stundenkontingent der bessere Kompromiss: Sie bietet garantierte Reaktionszeiten und planbare Kosten, während Ad-hoc-Beauftragung bei einem kritischen Ausfall keine verlässliche Reaktionszeit garantiert.

Warum reicht es nicht, Software nach dem Launch einfach laufen zu lassen?

Betriebssysteme, Browser und Bibliotheken ändern sich laufend. Ungepflegte Software verliert an Sicherheit und Kompatibilität und riskiert irgendwann eine teure Neuentwicklung statt kontinuierlicher, planbarer Pflege.