Der unsichtbare Aufwand: Was Kunden bei TYPO3-Projekten nicht sehen

Kurz zusammengefasst: Ein großer Teil der Arbeit an einer TYPO3-Website passiert im Hintergrund und bleibt für Kunden unsichtbar. Updates, Kompatibilitätsprüfungen und die Denkarbeit hinter jedem noch so kleinen Änderungswunsch kosten Zeit, auch wenn am Ende äußerlich nichts anders aussieht. Wer das nicht einordnen kann, hält laufende Betreuung schnell für überflüssig, bis genau das zum Problem wird.

Manche Kunden reagieren auf den Vorschlag, ein TYPO3-Update einzuspielen, mit einer einfachen Frage: Wieso, die Seite läuft doch. Seit fünf Jahren, manchmal seit zehn. Nichts ist kaputt, nichts sieht anders aus, also wofür zahlt man eigentlich noch. Die Antwort liegt in einem Teil der Arbeit, den Kunden strukturell nicht sehen können. Und genau das macht ihn so schwer zu vermitteln.

Läuft doch, warum was ändern?

Eine Website, die äußerlich seit Jahren unverändert läuft, hat in Wirklichkeit eine Menge Arbeit hinter sich, die niemand sieht. Genau dieser Widerspruch sorgt regelmäßig für Verwunderung, wenn eine Rechnung für Wartung oder Pflege ins Haus flattert, obwohl sich an der Seite scheinbar nichts verändert hat.

Das ist kein Vorwurf an Kunden. Wer sich nicht täglich mit Softwarepflege beschäftigt, hat keinen Grund, den Aufwand hinter einer stabil laufenden Website zu kennen. Hinzu kommt: TYPO3-Versionen haben einen klar begrenzten Support-Zeitraum. Auch ein System, das äußerlich unverändert läuft, bewegt sich stetig auf das Ende dieses Zeitraums zu, ohne dass man das von außen sieht. Genau deshalb lohnt es sich, diesen Aufwand einmal konkret zu benennen, statt ihn stillschweigend vorauszusetzen.

Wenn niemand mehr updatet: Sicherheit, DSGVO und Stand der Technik

Bleiben Updates und Pflege über Jahre aus, wird aus einem Komfortproblem irgendwann ein echtes Risiko. Veraltete Software ist ein bekanntes Einfallstor für Sicherheitslücken, und die DSGVO verlangt, personenbezogene Daten nach dem Stand der Technik zu schützen. Eine Website, die seit Jahren nicht mehr aktualisiert wurde, erfüllt dieses Kriterium in der Regel nicht mehr. Im Ernstfall bekommen Angreifer über eine bekannte, ungepatchte Sicherheitslücke in TYPO3 oder einer Extension Zugriff auf Backend oder Datenbank. Dann steht nicht nur ein technisches Problem im Raum, sondern möglicherweise auch eine Meldepflicht und ein Reputationsschaden, dessen Behebung deutlich teurer wird als jede Wartung zuvor.

Und es braucht dafür nicht einmal einen Angriff: Ältere Installationen oder in die Jahre gekommene Extensions binden nicht selten noch externe Google Fonts oder andere Drittanbieter-Skripte ein, ohne dass dafür eine Einwilligung eingeholt wird. Das lässt sich mit einem Blick in den Quelltext erkennen, ganz ohne technisches Vorwissen, und war in den letzten Jahren ein bekannter Abmahn-Klassiker. Ein missgünstiger Mitbewerber oder ein unzufriedener Dritter kann das jederzeit melden oder deswegen eine Abmahnung veranlassen, und schon steht eine Prüfung im Raum, ganz ohne dass vorher irgendetwas gehackt wurde.

In der Praxis begegnet einem gelegentlich ein Kunde, der auf Upgrade-Empfehlungen konsequent nicht reagiert, egal mit welchem Argument. Weder Sicherheit noch DSGVO noch die Aussicht auf steigende Folgekosten ändern etwas an der Haltung. Irgendwann ist der Punkt erreicht, an dem sich auch als Integrator die Frage stellt, ob man dieses Risiko weiter mittragen will oder dem Kunden ehrlich sagt, dass jemand anderes die Betreuung übernehmen sollte.

Das klingt hart, ist aber am Ende ein Schutz für beide Seiten.

Updates und Extension-Pflege: weniger Aufwand, aber nicht weniger Verantwortung

Regelmäßige Updates von TYPO3 und den eingesetzten Extensions sind der klassischste Teil dieser unsichtbaren Arbeit. Neue Versionen schließen Sicherheitslücken, sorgen für Kompatibilität und halten das System auf einem Stand, mit dem man in einem Jahr noch arbeiten kann.

Werkzeuge wie Renovate und (teil)automatisierte Deployments haben diesen Prozess in den letzten Jahren spürbar erleichtert, unabhängig davon, ob im Hintergrund GitHub Actions, GitLab CI oder ein anderes System läuft. Abhängigkeiten werden erkannt, Pull Requests automatisch erstellt, Tests laufen im Hintergrund. Der manuelle Aufwand sinkt dadurch tatsächlich.

Dazu kommt Fachwissen, das sich nicht automatisieren lässt. TYPO3-LTS-Versionen haben einen klar definierten Support-Zeitraum, üblicherweise drei Jahre aktive Pflege plus ein weiteres Jahr reine Sicherheitsupdates über die Extended Support. Vor einem größeren Versions-Upgrade hilft der im Core eingebaute Extension Scanner, veraltete oder entfernte APIs im eigenen Code frühzeitig aufzuspüren, und Werkzeuge wie TYPO3-Rector automatisieren einen Teil der nötigen Codeanpassungen. Wer außerdem die Advisories des TYPO3 Security Teams nicht im Blick behält, verpasst im Zweifel genau die Meldung, die aus einem optionalen ein dringendes Update macht.

Was bleibt, ist die Verantwortung. Jemand muss die vorgeschlagenen Updates bewerten, entscheiden, ob ein Update jetzt sinnvoll ist oder besser noch wartet, individuelle Extensions und Anpassungen auf Kompatibilität prüfen und im Zweifel auf einer Staging-Umgebung testen, bevor etwas live geht. Automatisierung nimmt Arbeit ab, aber nicht die Entscheidung und nicht die Haftung dafür, dass am Ende alles funktioniert.

Der Rattenschwanz hinter jedem Ticket

Selbst eine simple Änderung wie eine neue Buttonfarbe zieht mehr Arbeit nach sich, als sie auf den ersten Blick vermuten lässt. Ein Kunde schreibt ein Ticket: Button bitte von Rot auf Grün ändern. Klingt nach zwei Minuten Aufwand.

Tatsächlich beginnt die Arbeit schon beim Lesen des Tickets. Man überlegt, wo dieser Button überall verwendet wird, ob die Änderung isoliert bleibt oder an anderer Stelle Folgen hat, ob Grün zum bestehenden Design passt. Diese Denkarbeit dauert manchmal eine halbe Stunde oder länger, bevor überhaupt eine Zeile Code geschrieben wird.

Der naheliegende Einwand, bei einer sauberen Komponentenstruktur sei das doch trivial, weil die Farbe ja nur an einer einzigen Stelle definiert ist, stimmt nur auf den ersten Blick. Auch dann bleibt die Frage, wo dieser Button-Typ überall auftaucht, ob Grün an anderer Stelle bereits eine andere Bedeutung trägt, etwa als Signal für "erfolgreich" oder "aktiv", und ob dadurch Screenshots, Styleguide oder Dokumentation nicht mehr aktuell sind. Eine Komponente macht die technische Umsetzung schneller, ersetzt aber nicht das Nachdenken darüber, was diese eine Änderung sonst noch berührt.

Danach kommen die Umsetzung, die Antwort an den Kunden und im besten Fall die Dokumentation der Änderung im Code, im Ticketsystem oder im Git-Log. Diese Dokumentation ist kein Selbstzweck, sondern eine Absicherung für die nächste Änderung, ganz gleich, ob sie in einem Jahr von derselben Person oder von jemand anderem umgesetzt wird. All das gehört zur Aufgabe dazu, taucht aber selten in der Wahrnehmung des Kunden auf. Sichtbar ist nur der grüne statt der rote Button.

Den unsichtbaren Aufwand sichtbar machen

Ein Teil des Problems lässt sich mit einem einfachen Mittel entschärfen: einem kurzen, regelmäßigen Wartungsprotokoll für den Kunden. Ein bis zwei Absätze pro Quartal oder Monat reichen, mit den durchgeführten Updates, geprüften oder geschlossenen Sicherheitslücken und der Anzahl bearbeiteter Tickets. Kein Verkaufsargument, keine Rechtfertigung, einfach eine kurze Dokumentation dessen, was ohnehin passiert ist.

Der naheliegende Einwand: Wer schreibt so ein Protokoll denn nun schon wieder, ist das nicht selbst wieder unbezahlte Zusatzarbeit? Genau hier hilft KI. Ein Sprachmodell mit begrenztem Zugriff auf das Git-Log eines Projekts kann daraus in wenigen Minuten einen laienverständlichen Bericht erstellen, einfach mit der Anweisung, Fachbegriffe zu vermeiden und sich an einen technisch nicht versierten Endkunden zu richten. Der Aufwand dafür liegt eher bei Minuten als bei Stunden und lässt sich mit einem festen Prompt oder einem entsprechenden Agenten-Workflow fast vollständig automatisieren.

Das funktioniert unabhängig vom Abrechnungsmodell und macht aus unsichtbarer Arbeit zumindest ein sichtbares Ergebnis. Manche Kunden lesen es nie, andere fragen beim ersten Mal nach, was eine bestimmte Sicherheitslücke konkret bedeutet hätte. Beides ist ein besserer Ausgangspunkt als eine Rechnung ohne jeden Kontext.

Warum sich Pauschalen und Wartungsverträge lohnen

Genau wegen dieses unsichtbaren Aufwands ergeben Wartungsverträge oder Pauschalen für viele Kunden mehr Sinn als eine Abrechnung nach einzelnem Aufwand. Bei reiner Stundenabrechnung entsteht schnell eine unbequeme Diskussion darüber, ob eine halbe Stunde Denkarbeit für einen Buttonfarbwechsel wirklich berechnet werden darf. Häufig wird dieser Teil dann stillschweigend nicht abgerechnet, was auf Dauer beim Integrator zu Frust führt, ohne dass der Kunde davon je etwas mitbekommt.

Eine Pauschale nimmt diese Diskussion vorweg. Der Aufwand ist eingepreist, bevor die Frage überhaupt gestellt wird. Das funktioniert nicht bei jedem Kunden und jedem Projekt gleich gut, manche bevorzugen weiterhin Einzelabrechnung, und das ist legitim. Aber wer regelmäßig mit dem unsichtbaren Aufwand kämpft, sollte Pauschalen und Wartungsverträge zumindest als ernsthafte Option prüfen, nicht als Verkaufsargument, sondern als ehrlicheren Weg, Arbeit abzubilden, die ohnehin anfällt.

Am besten von Anfang an ansprechen

Wer diesen unsichtbaren Aufwand nicht rückwirkend rechtfertigen will, spricht ihn am besten schon beim Projektstart an, nicht erst, wenn die erste Wartungsrechnung für Verwunderung sorgt. Ein paar Ansatzpunkte, die sich in der Praxis bewährt haben:

• Wartung als fester Bestandteil des Angebots, nicht als Zusatzoption: Schon im ersten Angebot eine eigene, kurz erklärte Position für laufende Pflege einplanen, statt sie erst nach dem Launch nachzureichen.
• Ein kurzes Gespräch direkt nach dem Go-Live: Aktiv erklären, was jetzt beginnt, Update-Rhythmus, Support-Zeiträume, wie und wie oft berichtet wird. Das nimmt der Wartung später den Überraschungseffekt.
• Das erste Wartungsprotokoll unaufgefordert liefern: Der erste Bericht kommt am besten, bevor der Kunde danach fragt. Das zeigt den Wert, statt ihn nur zu behaupten.
• Eine kurze schriftliche Wartungsvereinbarung als Standard, nicht als Sonderwunsch: Selbst bei reiner Stundenabrechnung hilft ein knapper Rahmen von Anfang an, spätere Diskussionen zu vermeiden.

Fazit

Der unsichtbare Aufwand hinter einer TYPO3-Website ist real, auch wenn er sich kaum in einer Rechnung sichtbar machen lässt. Er steckt in Updates, die dank Automatisierung leichter, aber nicht überflüssig geworden sind. Er steckt in der Denkarbeit hinter jedem noch so kleinen Ticket. Und er steckt in den Risiken, die entstehen, wenn er über Jahre ignoriert wird.

Wer das einmal verstanden hat, stellt die Frage "läuft doch, warum was ändern" nicht mehr.

Falls dir beim Lesen gerade ein bestimmter Kunde eingefallen ist, der genau das nicht versteht: Schick ihm einfach den Link zu diesem Artikel. Manchmal wirkt das besser als jedes weitere Gespräch.