Kurz gefasst:
Die meisten digitalen Produkte benötigen nach dem Launch kein Vollzeit-Support-Team. Was sie brauchen, ist ein kleines, festes Team auf Retainer-Basis, das das System während der Geschäftszeiten überwacht, Fehler behebt und geplante Verbesserungen in festen Zeitblöcken umsetzt. Planen Sie jährlich 10–20 % der Entwicklungskosten für den laufenden Betrieb ein und kalkulieren Sie das Budget für wachstumsorientierte Weiterentwicklungen separat. Dieser Leitfaden erläutert, was diese Wartung umfasst, was sie kostet und wie Sie sie vertraglich regeln.
Ein digitales Produkt ist Software, die Ihre Kunden direkt nutzen oder kaufen: eine Webanwendung, eine mobile App, eine Plattform, eine API, ein Abonnement-Dienst oder ein herunterladbares Asset wie eine Vorlage, ein Kurs oder ein Bericht. Es findet kein physischer Austausch statt. Doch im Hintergrund gibt es weiterhin Server, Abhängigkeiten, Browser, App-Stores, Zahlungsanbieter und Sicherheitshinweise – und all das verändert sich ständig, ganz egal, ob jemand Ihren Code anfasst oder nicht.
Genau dieser Unterschied überrascht viele Produktverantwortliche. Ein physisches Produkt ist fertig, sobald es ausgeliefert wird. Ein digitales Produkt gleicht eher einem Boot auf dem Wasser: Der Rumpf muss regelmäßig gereinigt werden, ein Leck muss sofort gestopft werden, sobald es auftritt, und ein größeres Segel ist ein eigenes Projekt. Der Tag des Launches ist der Moment, in dem das Boot zu Wasser gelassen wird – nicht der Moment, in dem die Arbeit endet. Wenn Sie digitale Produkte verkaufen oder diese als Motor Ihres Dienstleistungsgeschäfts betreiben, ist dies der Tag, an dem die laufenden Kosten beginnen.
Sobald ein digitales Produkt live geht, machen sich Produktverantwortliche Gedanken über die Wartung. Das ist eine verbreitete und durchaus berechtigte Sorge. Dies ist der Punkt im Lebenszyklus, an dem das Produkt die meiste Unterstützung benötigt, und gleichzeitig der Punkt, an dem sich das Entwicklungs- und Designteam zurückzieht, da es wirtschaftlich nicht sinnvoll ist, das gesamte Team weiterhin voll einzubinden.
Dadurch entsteht für beide Seiten ein Problem. Der Produktverantwortliche verliert das Team, das den Kontext kennt, sodass niemand verfügbar ist, wenn ein dringendes Problem auftritt. Die Agentur erhält regelmäßige, ungeplante Support-Anfragen, während dieselben Leute bereits an anderen Projekten arbeiten. Kontextwechsel unter Zeitdruck, Terminverschiebungen bei neuen Aufgaben und am Ende leiden zwei Produkte statt nur eines.
Was Sie stattdessen brauchen, ist eine ausgewogene Lösung: Produktverantwortliche erhalten bei Bedarf Unterstützung durch ein Team, und Projektteams werden nach Abschluss eines Projekts nicht ständig unterbrochen. Um dies zu erreichen, müssen Sie wissen, was nach der Bereitstellung eines Produkts tatsächlich getan werden muss.
Sobald ein Produkt live ist und sich in der sogenannten Wartungsphase befindet, müssen verschiedene Aufgaben ausgeführt werden. Es ist entscheidend, die Art dieser Aufgaben zu verstehen, da jede Kategorie anders eingekauft, geplant und bepreist wird. Sie sind in der Regel wie folgt gegliedert:
Diese Aufteilung haben wir nicht erfunden. ISO/IEC/IEEE 14764:2022, der internationale Standard für Softwarewartung, formalisiert die Arbeit nach der Bereitstellung in vier Kategorien: korrektiv, adaptiv, perfektiv und präventiv. Unser Drei-Linien-Modell lässt sich direkt darauf abbilden. Präventiv bleibt präventiv, korrektiv bleibt korrektiv, und wir fassen die beiden Erweiterungstypen, adaptiv und perfektiv, zu einer einzigen Linie zusammen, die wir evolutivnennen, da sie kommerziell auf die gleiche Weise eingekauft und geplant werden.
Die Forschung hinter dem Standard ist sich in einem Punkt einig, der die meisten Produktverantwortlichen überrascht: Der Großteil des Wartungsaufwands entfällt auf Erweiterungen, nicht auf die Behebung von Fehlern. In der klassischen Studie von Lientz, Swanson und Tompkinsmachte allein die perfektive Arbeit, also die Erweiterung, etwa 60 % des Wartungsaufwands aus, während die korrektive Fehlerbehebung bei unter einem Fünftel lag. Dieses Ergebnis wurde seitdem wiederholt bestätigt.
Bei Imaginary Cloud führen wir diese drei Arten als drei separate Linien in einem sogenannten Drei-Linien-Retainer: jeweils eine vertraglich vereinbarte Linie für präventive, korrektive und evolutive Arbeiten, die unabhängig voneinander bepreist und geplant werden, anstatt aus einem gemeinsamen Stundenpool zu stammen.
Warum diese Aufteilung? Weil sich die drei Bereiche unterschiedlich verhalten. Präventive Arbeit ist vorhersehbar und kann geplant werden. Korrektive Arbeit ist unvorhersehbar und erfordert eine Reaktionsverpflichtung. Evolutive Arbeit wird wie jedes andere Projekt geplant. Unserer Erfahrung nach ist ein undifferenzierter Stundenpool der häufigste Grund dafür, dass ein Wartungsbudget schon früh im Jahr aufgebraucht ist: Ein einziger Vorfall im ersten Quartal verschlingt die Stunden, die eigentlich für zwölf Monate Patching vorgesehen waren, und die geplanten Verbesserungen fallen als Erstes weg.
In allen Situationen, die unter präventive und korrektive Wartung fallen, benötigt der Produktverantwortliche ein Team, das sich um bestehende Probleme kümmert. Die meisten digitalen Produkte erfordern jedoch kein Team, das rund um die Uhr im Einsatz ist. Was sie brauchen, ist ein Team, das das System im Blick behält und bei Ausfällen eingreift. Mit den richtigen Maßnahmen ist eine moderne Infrastruktur stabil genug, sodass für die meisten Produkte ein Support während der Geschäftszeiten ausreicht.
Die für die Wartung vorgesehene Zeit wird in der Regel über einen Retainer vereinbart: eine feste monatliche Gebühr, die ein vereinbartes Zeitkontingent eines festen Teams reserviert, unabhängig davon, ob Sie dieses in dem Monat vollständig ausschöpfen. Sie bezahlen ebenso sehr für die Verfügbarkeit und das vorhandene Kontextwissen wie für die geleisteten Stunden. Um dies effizient zu gestalten, betreut das Team mehrere Produkte gleichzeitig und führt standardisierte Prozesse für Dienste wie Serverüberwachung und Sicherheits-Patches durch.
In manchen Fällen ist ein 24/7-Support tatsächlich erforderlich, doch dabei handelt es sich um einen völlig anderen Dienst. Rechnen Sie mit einem Aufpreis, der in der Regel an Unternehmen gezahlt wird, die sich auf Wartungsverträge spezialisiert haben, da dies eine Schichtplanung und Eskalationsverfahren erfordert, die nur in deutlich größerem Maßstab wirtschaftlich sind.
Bei der korrektiven Wartung werden Reaktionszeiten vereinbart; unklare Formulierungen führen hier später oft zu Konflikten. Eine praktikable Service-Level-Vereinbarung legt für jeden Schweregrad eines Problems drei Dinge fest: wie schnell der Eingang der Meldung bestätigt wird, wie schnell mit der Arbeit begonnen wird und welches Ziel für eine Fehlerbehebung oder einen Workaround gilt. Eine gängige Struktur für einen Retainer während der Geschäftszeiten sieht wie folgt aus:
| Schweregrad | Beispiel | Bestätigung | Zielauflösung |
|---|---|---|---|
| Kritisch | Produkt ausgefallen, Checkout fehlerhaft, Daten gefährdet | Innerhalb von 1 Geschäftsstunde | Am selben Arbeitstag, Behelfslösung zuerst |
| Hoch | Hauptfunktion für viele Benutzer fehlerhaft | Innerhalb von 4 Geschäftsstunden | Nächster Arbeitstag |
| Mittel | Nicht-kritischer Fehler, Behelfslösung vorhanden | Innerhalb von 1 Arbeitstag | Nächstes geplantes Release |
| Niedrig | Kosmetisches Problem, geringfügige Inhaltsänderung | Innerhalb von 2 Arbeitstagen | In geplante Arbeiten gebündelt |
Legen Sie die Definitionen für jeden Schweregrad vor der Vertragsunterzeichnung fest, nicht erst beim ersten Vorfall. Vereinbaren Sie, wer berechtigt ist, ein kritisches Problem zu deklarieren. Und legen Sie fest, was mit den geplanten Arbeiten des Monats geschieht, wenn ein solcher Fall eintritt.
Support während der Geschäftszeiten funktioniert nur, wenn das System Sie selbst über Probleme informiert, anstatt darauf zu warten, dass ein Kunde dies tut. Eine solide Monitoring-Basis umfasst die Überprüfung von Uptime und Endpunkten, Fehlerverfolgung mit Alarmierung, Log-Aggregation, Infrastruktur-Metriken wie CPU, Arbeitsspeicher und Festplatte, Datenbankleistung und langsame Abfragen, Backup-Verifizierung mit getesteter Wiederherstellung sowie Abhängigkeits- und Schwachstellen-Scans auf Basis öffentlicher Datenbanken wie der National Vulnerability Database und den Richtlinien von OWASP.
Letzteres macht aus der präventiven Wartung, die sonst nur eine Kalenderübung wäre, eine echte Schutzmaßnahme. Wenn eine Schwachstelle in einem Framework bekannt wird, von dem Sie abhängig sind, stellt sich nicht die Frage, ob Sie diese beheben werden. Die Frage ist, wie viele Tage vergehen, bis Sie davon erfahren.
Bei der evolutiven Wartung geht es vor allem um geschäftliches Wachstum und die Verbesserung von Services. Sie lässt sich zeitnah planen und umsetzen. Erstellen Sie eine Aufgabenliste und bitten Sie Ihren Technologiepartner, ein Team zusammenzustellen, das diese in ein paar Sprints abarbeitet: feste Entwicklungsblöcke, die in der Regel ein bis zwei Wochen dauern, mit einem zu Beginn vereinbarten Umfang und einem Release am Ende.
Evolutive Aufgaben in einer eigenen Linie und in geplanten Sprints zu bearbeiten, anstatt sie über den Support-Kanal abzuwickeln, schützt beide Seiten. Der Product Owner erhält einen vorhersehbaren Release-Rhythmus und transparente Kosten pro Block. Das Team kann seine Kapazitäten planen – was letztlich bedeutet, dass niemand kurzfristig von einem anderen Projekt abgezogen wird. Lesen Sie Wasserfall vs. Agile: Wann man was einsetzt um zu erfahren, wie sich die beiden Planungsstile beim Strukturieren dieser Blöcke unterscheiden.
Hier findet auch die Arbeit am Wachstum statt. Die Umgestaltung eines Produkts, damit es mehr Nutzer bewältigen kann, ist ein klassisches evolutives Projekt: Wir haben die App-Builder-Umgebung von GoodBarber auf eine skalierbarere Architektur umgestellt – genau auf diese Weise. Mehr dazu erfahren Sie in der GoodBarber Composer Fallstudie.
Der größte Kostentreiber bei der evolutiven Wartung ist nicht der Umfang einer Funktion. Es ist die Frage, wie schwer sich die bestehende Codebasis verändern lässt. Diese Schwierigkeit hat einen Namen: technische Schulden. Wenn sie nicht verwaltet werden, treiben sie die Kosten für jede neue Erweiterung schleichend in die Höhe. Robert Glass hat dies bereits vor Jahrzehnten treffend formuliert: Die Hauptaufgabe bei der Wartung besteht darin, das bestehende Produkt zu verstehen, bevor man sicher Änderungen vornehmen kann.
Der Weg, diese Kosten sichtbar zu machen, ist die Messung. Ein regelmäßiges Code-Audit , das Wartbarkeit, Komplexität und Testabdeckung bewertet, zeigt Ihnen, wo die Schulden liegen, bevor sie ein Release gefährden. Für GoodBarber haben wir eine Pseudocode-Dokumentation von 195 Vorlagen erstellt, wie in der Fallstudie zur Code-Standardisierungbeschrieben. So konnten vor einem größeren Umbau architektonische Entscheidungen auf Basis von Fakten statt auf Vermutungen getroffen werden. Einen umfassenderen Überblick bietet unser Leitfaden zum Thema Umgang mit technischen Schulden , in dem wir praktische Optionen aufzeigen.
Digitale Produkte sind kommerziell nicht gleich. Die Art und Weise, wie Ihr Produkt Geld verdient, bestimmt, was Ihnen Ausfallzeiten kosten, wie schnell Sie Patches einspielen müssen und welcher der drei Wartungsbereiche am stärksten belastet wird. Fünf Modelle decken den Großteil des Marktes ab.
Der praktische Nutzen dieser Liste liegt in der Dimensionierung. Ermitteln Sie zuerst, was eine Stunde Ausfall in Ihrem Modell kostet, und wählen Sie dann das passende Support-Paket. Ein Marktplatz mit hohem Transaktionsvolumen und ein Vorlagen-Shop mit fünfzig Verkäufen im Monat sind beides digitale Produkte, sollten aber nicht den gleichen Support einkaufen.
Nach dem Launch neigt man dazu, das Team auf den arbeitsintensivsten Monat auszulegen. Das lässt die Wartungskosten unbezahlbar erscheinen, ist aber eine falsche Kalkulation, da der arbeitsintensivste Monat nicht dem Durchschnitt entspricht.
Für die meisten Produkte im ersten Jahr ist ein fraktioniertes Team sinnvoller als ein festes: ein Teilzeit-Entwickler, der den Kontext des Produkts kennt, ein Teilzeit-DevOps- oder Plattform-Ingenieur für Infrastruktur und Monitoring sowie Zugriff auf einen Designer und einen Lead für weiterführende Entwicklungen. Das kostet nur einen Bruchteil einer Vollzeitstelle und ist einem einzelnen Junior-Entwickler in Sachen Verfügbarkeit überlegen, da Urlaubszeiten, Krankheitsfälle und die nötige Spezialisierung abgedeckt sind. Wenn ein Produkt ein eigenes Squad benötigt, bewährt sich auch ein Embedded-Modell: Wir haben das Team von AppTweak als integrierte Frontend-Einheit unterstützt und deren Prozesse übernommen. Drei Vertragsmodelle decken nahezu jede Situation ab:
| Modell | Was Sie bekommen | Ideal für |
|---|---|---|
| Pauschale für Geschäftszeiten | Feste monatliche Gebühr, vereinbartes Stundenkontingent, Reaktionszusage während der Arbeitszeiten. Nicht genutzte Stunden werden in der Regel gedeckelt und nicht angespart. | Die meisten Produkte; das Modell, für das der Three-Line-Retainer entwickelt wurde |
| Abrechnung nach Aufwand (Time & Materials) | Sie zahlen nur, was Sie nutzen, keine Verfügbarkeitsgarantie. Auf dem Papier am günstigsten, bei einem Vorfall am teuersten, da Sie sich in die Warteschlange einreihen. | Interne Werkzeuge, geringe kommerzielle Relevanz |
| 24/7 oder erweiterter Schutz | Schichtbesetzung, Rufbereitschafts-Eskalation, Aufpreis. | Transaktionsplattformen, regulierte oder sicherheitskritische Dienste |
Entscheiden Sie sich für das passende Modell, indem Sie fragen, was eine Stunde Ausfallzeit kostet, und nicht, wie hoch die monatliche Pauschale ist. Unternehmen, die digitale Produkte kontinuierlich und nicht in Projektzyklen vertreiben, stellen fast immer fest, dass die Pauschale die kostengünstigere Variante ist.
Bei den von uns entwickelten und betreuten Produkten liegen die Kosten für präventive und korrektive Wartung bei jährlich 10–20 % der ursprünglichen Entwicklungskosten. Diesen Rahmen legen wir auch bei der Budgetierung mit unseren Kunden zugrunde. Das deckt sich gut mit allgemeinen Untersuchungen zu den Lebenszykluskosten von Software: Robert Glass beziffert den Wartungsanteil auf 40–80 % der gesamten Lebenszykluskosten, im Durchschnitt auf 60 %, in Facts and Fallacies of Software Engineering (2002). Über die gesamte Lebensdauer eines Produkts hinweg sind das also mehr als die ursprünglichen Entwicklungskosten.
Praktisch ausgedrückt: Für ein Produkt mit Entwicklungskosten von 150.000 £ sollten Sie für den laufenden Betrieb – exklusive neuer Funktionen – ein jährliches Budget von etwa 15.000 £ bis 30.000 £ einplanen. Wo genau Sie sich in diesem Bereich bewegen, hängt vom gewählten Geschäftsmodell, der Anzahl der Drittanbieter-Integrationen und dem Umfang der von Ihnen kontrollierten Technologie-Stacks ab.
Die evolutionäre Wartung ist in dieser Zahl nicht enthalten, da sie davon abhängt, wie stark das Produkt wachsen soll. Betrachten Sie dies als separaten Budgetposten, als dritte Säule des Retainers, und bemessen Sie ihn anhand Ihrer Roadmap statt anhand der Entwicklungskosten. Ein Produkt in einer aktiven Wachstumsphase kann leicht mehr für evolutionäre Arbeiten ausgeben als die präventive und korrektive Wartung zusammen kosten.
Zwei Kostenfaktoren werden bei der ersten Budgetplanung regelmäßig vergessen, fallen dann aber dennoch an: Dienste von Drittanbietern (Hosting, Monitoring, Fehlerverfolgung und kostenpflichtige APIs) sowie der Aufwand für App-Store-Vorgaben und Compliance, um ein mobiles Produkt bei sich ändernden Plattformanforderungen weiterhin veröffentlichen zu können.
Arbeiten Sie von Anfang an gemeinsam mit Ihrem Software-Entwicklungspartner an den Antworten. Sprechen Sie offen über Ihre Bedenken und legen Sie vertraglich fest, was im Ernstfall passiert, anstatt sich blind auf gegenseitiges Wohlwollen zu verlassen. So vermeiden Sie Situationen, in denen nach dem Launch Probleme auftreten, die sich nicht ohne Konflikte lösen lassen. Denn wenn es dazu kommt, sind Ihre Nutzer die Ersten, die darunter leiden – und in der Folge Ihr gesamtes Unternehmen.
Etwas, das Kunden nutzen oder kaufen, ohne dass physische Güter den Besitzer wechseln: eine Web- oder Mobile-App, eine Plattform, eine API, ein Abonnement-Dienst oder ein herunterladbares Asset wie eine Vorlage, ein Kurs oder ein Bericht. All diese Produkte basieren auf Infrastruktur, Drittanbieter-Diensten und Code-Bibliotheken, die sich ständig ändern. Deshalb verursacht jedes digitale Produkt nach dem Start laufende Kosten.
Planen Sie jährlich 10–20 % der ursprünglichen Entwicklungskosten für präventive und korrektive Wartung ein. Ein Produkt mit Entwicklungskosten von 150.000 £ verursacht also etwa 15.000 £ bis 30.000 £ pro Jahr. Evolutive Wartung, also die Entwicklung neuer Funktionen und Erweiterungen, wird separat basierend auf Ihrer Roadmap budgetiert.
Die meisten nicht. Mit Monitoring, Alarmierung und einer Support-Vereinbarung während der Geschäftszeiten sind die meisten Produkte ausreichend abgedeckt. Eine Rund-um-die-Uhr-Betreuung ist dann gerechtfertigt, wenn eine Stunde Ausfallzeit direkte finanzielle Verluste, regulatorische Probleme oder Sicherheitsrisiken nach sich zieht. Solche Leistungen werden in der Regel bei spezialisierten Wartungsanbietern eingekauft.
Dabei handelt es sich um Arbeiten, die ein bestehendes Produkt verbessern oder erweitern, anstatt es nur am Laufen zu halten: neue Funktionen, Performance-Optimierungen, Kapazitätserweiterungen oder Integrationen. Dies entspricht der adaptiven und perfektiven Wartung nach ISO 14764, wird wie jede andere Entwicklungsarbeit in Sprints umgesetzt und sollte vertraglich sowie budgetär vom Support getrennt werden.
Präventive Wartung ist geplante Arbeit, um Ausfälle zu verhindern, wie das Einspielen von Sicherheitsupdates oder das Erneuern von Zertifikaten. Korrektive Wartung ist die reaktive Arbeit, nachdem bereits ein Fehler aufgetreten ist, etwa die Wiederherstellung eines ausgefallenen Servers. Präventive Arbeit ist vorhersehbar und planbar; bei korrektiver Arbeit ist eine verbindliche Reaktionszeit entscheidend.
Ein festes Team, ein vereinbartes monatliches Stundenkontingent, Reaktions- und Lösungsziele je nach Schweregrad, ein definiertes Monitoring- und Alarmierungskonzept, einen Zeitplan für Updates sowie einen klaren Prozess für den Umgang mit geplanten Arbeiten im Falle eines kritischen Vorfalls – inklusive der Festlegung, wer einen solchen Vorfall deklarieren darf.
Der technische Aufwand ist geringer als bei einem SaaS-Produkt, aber die kommerzielle Infrastruktur muss dennoch gewartet werden: Checkout, Zahlungsanbieter-Integrationen, Lizenzbereitstellung, Datei-Hosting und Zugriffskontrolle. Das größte Risiko liegt im präventiven Bereich, da die Komponenten, die am ehesten ausfallen, Drittanbieter-Dienste sind, die sich nach ihrem eigenen Zeitplan ändern.
Das ist möglich und sinnvoll, sobald das Produkt groß genug ist, um ein Vollzeit-Team dauerhaft auszulasten. Unterhalb dieser Schwelle deckt ein externes Team auf Retainer-Basis Urlaubszeiten, Krankheitsfälle und Spezialwissen ab, das ein einzelner interner Mitarbeiter oft nicht leisten kann – und das meist zu Kosten, die unter einem Vollzeitgehalt liegen.
Wenn Ihr Produkt kurz vor dem Start steht oder bereits live ist und nur informell betreut wird, lohnt es sich, die Wartung auf ein solides Fundament zu stellen, bevor der erste Zwischenfall Sie dazu zwingt. Unser Team kann Ihr aktuelles Setup prüfen und ein Wartungsmodell vorschlagen, das sich am tatsächlichen Risiko Ihres Produkts orientiert, statt nur den Worst Case abzudecken.
Sprechen Sie mit uns über Support nach dem Launch und wir gehen gemeinsam durch, was Ihr Produkt benötigt und welche Kosten auf Sie zukommen. Sie können hier einen Termin vereinbaren.
CEO von Imaginary Cloud und Mitautor des Buches Product Design Process. Ich mag Essen, Wein und Krav Maga (nicht unbedingt in dieser Reihenfolge).
Alexandra Mendes ist Senior Growth Specialist bei Imaginary Cloud und verfügt über mehr als 3 Jahre Erfahrung in der Erstellung von Texten über Softwareentwicklung, KI und digitale Transformation. Nach Abschluss eines Frontend-Entwicklungskurses erwarb Alexandra einige praktische Programmierkenntnisse und arbeitet nun eng mit technischen Teams zusammen. Alexandra ist begeistert davon, wie neue Technologien Wirtschaft und Gesellschaft prägen. Sie liebt es, komplexe Themen in klare, hilfreiche Inhalte für Entscheidungsträger umzuwandeln.
People who read this post, also found these interesting:
.webp)
