The Hidden Effort: What Customers Don't See in TYPO3 Projects

In a nutshell: A large part of the work on a TYPO3 website happens behind the scenes and remains invisible to customers. Updates, compatibility checks, and the thought process behind even the smallest change request take time—even if, on the surface, nothing looks any different in the end. Anyone who doesn’t understand this will quickly dismiss ongoing maintenance as unnecessary—until that very fact becomes a problem.

Some clients react to the suggestion of installing a TYPO3 update with a simple question: “Why? The site is working just fine.” It’s been running for five years—sometimes even ten. Nothing is broken, nothing looks different, so what exactly are they still paying for? The answer lies in a part of the work that clients simply can’t see. And that’s exactly what makes it so hard to explain.

It’s working fine—why change anything?

A website that has been running unchanged on the surface for years has, in reality, undergone a great deal of work that no one sees. It’s precisely this contradiction that regularly causes surprise when a bill for maintenance or upkeep arrives, even though nothing on the site seems to have changed.

This isn’t a criticism of clients. Anyone who doesn’t deal with software maintenance on a daily basis has no reason to know the effort behind a stable website. On top of that, TYPO3 versions have a clearly defined support period. Even a system that appears to be running unchanged is steadily approaching the end of this period, without anyone noticing from the outside. That’s exactly why it’s worth explicitly outlining this effort rather than simply taking it for granted.

When No One Updates Anymore: Security, GDPR, and State of the Art

If updates and maintenance are neglected for years, what starts as a minor inconvenience eventually becomes a real risk. Outdated software is a well-known gateway for security vulnerabilities, and the GDPR requires that personal data be protected in accordance with the state of the art. A website that hasn’t been updated for years generally no longer meets this criterion. In the event of an incident, attackers can gain access to the backend or database through a known, unpatched security vulnerability in TYPO3 or an extension. This results not only in a technical problem but potentially also in a mandatory reporting obligation and reputational damage, the cost of remedying which will be significantly higher than any previous maintenance costs.

And it doesn’t even take an attack for this to happen: Older installations or outdated extensions often still incorporate external Google Fonts or other third-party scripts without obtaining consent. This can be identified with a quick glance at the source code—no technical knowledge required—and has been a common cause for cease-and-desist letters in recent years. A jealous competitor or a dissatisfied third party can report this at any time or initiate a cease-and-desist letter over it, and suddenly an investigation is on the table—without anything having been hacked beforehand.

In practice, one occasionally encounters a client who consistently ignores upgrade recommendations, no matter what arguments are presented. Neither security nor the GDPR nor the prospect of rising follow-up costs changes this stance. At some point, even as an integrator, you reach the point where you have to ask yourself whether you want to continue bearing this risk or honestly tell the customer that someone else should take over their support.

That may sound harsh, but in the end, it protects both sides.

Updates and Extension Maintenance: Less Effort, but No Less Responsibility

Regular updates to TYPO3 and the extensions in use are the most classic part of this behind-the-scenes work. New versions patch security vulnerabilities, ensure compatibility, and keep the system up to a standard that will still be usable a year from now.

Tools like Renovate and (partially) automated deployments have noticeably simplified this process in recent years, regardless of whether GitHub Actions, GitLab CI, or another system is running in the background. Dependencies are detected, pull requests are created automatically, and tests run in the background. This actually reduces the manual effort required.

On top of that, there’s expertise that can’t be automated. TYPO3 LTS versions have a clearly defined support period, typically three years of active maintenance plus an additional year of security-only updates via Extended Support. Before a major version upgrade, the Extension Scanner built into the core helps detect outdated or deprecated APIs in your own code early on, and tools like TYPO3-Rector automate some of the necessary code adjustments. Furthermore, if you don’t keep an eye on the TYPO3 Security Team’s advisories, you might miss the very notification that turns an optional update into an urgent one.

What remains is the responsibility. Someone must evaluate the proposed updates, decide whether an update makes sense now or if it’s better to wait, check individual extensions and customizations for compatibility, and, if in doubt, test them in a staging environment before anything goes live. Automation reduces the workload, but it doesn’t take away the decision-making or the liability for ensuring that everything works in the end.

The Chain Reaction Behind Every Ticket

Even a simple change like a new button color entails more work than it might seem at first glance. A customer submits a ticket: “Please change the button from red to green.” Sounds like a two-minute job.

In reality, the work begins as soon as you read the ticket. You have to consider where this button is used throughout the system, whether the change is isolated or will have consequences elsewhere, and whether green fits the existing design. This thought process can sometimes take half an hour or longer before a single line of code is even written.

The obvious objection—that with a clean component structure, this should be trivial because the color is defined in only one place—is true only at first glance. Even then, the question remains: where does this button type appear throughout the system? Does green already have a different meaning elsewhere—for example, as a signal for “successful” or “active”? And does this mean that screenshots, the style guide, or documentation are no longer up to date? A component speeds up the technical implementation, but it doesn’t replace the need to think through what else this single change might affect.

Next come the implementation, the response to the client, and—in the best-case scenario—documentation of the change in the code, the ticket system, or the Git log. This documentation isn’t an end in itself, but rather a safeguard for the next change, regardless of whether it’s implemented a year from now by the same person or by someone else. All of this is part of the job, but it rarely comes to the customer’s attention. All they see is the green button instead of the red one.

Making the Invisible Effort Visible

Part of the problem can be mitigated with a simple solution: a brief, regular maintenance report for the client. One or two paragraphs per quarter or month are enough, detailing the updates performed, security vulnerabilities that were tested or patched, and the number of tickets resolved. No sales pitch, no justification—just a brief documentation of what happened anyway.

The obvious objection: Who’s going to write such a report anyway—isn’t that just more unpaid extra work? This is exactly where AI comes in. A language model with limited access to a project’s Git log can generate a report understandable to non-technical readers in just a few minutes—simply by instructing it to avoid technical jargon and address a non-technical end customer. The effort involved is measured in minutes rather than hours and can be almost completely automated using a fixed prompt or an appropriate agent workflow.

This works regardless of the billing model and turns invisible work into at least a visible result. Some clients never read it; others ask right away what a specific security vulnerability would have meant in concrete terms. Both are a better starting point than an invoice without any context.

Why Flat Rates and Maintenance Contracts Are Worth It

It is precisely because of this invisible effort that maintenance contracts or flat rates make more sense for many customers than billing based on individual tasks. With pure hourly billing, an uncomfortable discussion can quickly arise about whether half an hour of thinking time for changing a button’s color should really be billed. Often, this part is then tacitly left off the bill, which leads to frustration for the integrator over time, without the client ever noticing.

A flat fee preempts this discussion. The effort is factored into the price before the question is even asked. This doesn’t work equally well for every customer and every project; some still prefer itemized billing, and that’s perfectly legitimate. But anyone who regularly struggles with this “invisible” effort should at least consider flat rates and maintenance contracts as a serious option—not as a sales pitch, but as a more honest way to account for work that needs to be done anyway.

Best to address this from the start

If you don’t want to have to justify this invisible effort retroactively, it’s best to address it right at the start of the project—not only after the first maintenance invoice causes surprise. Here are a few approaches that have proven effective in practice:

• Includemaintenance as an integral part of the proposal, not as an add-on option: Include a separate, briefly explained line item for ongoing maintenance in the initial proposal, rather than submitting it after the launch.
• A brief discussion immediately after go-live: Actively explain what’s about to begin, the update schedule, support hours, and how and how often reports will be provided. This eliminates any surprises regarding maintenance later on.
• Provide the first maintenance report unsolicited: It’s best to send the first report before the client even asks for it. This demonstrates value rather than just claiming it.
• A brief written maintenance agreement as standard, not as a special request: Even with pure hourly billing, a concise framework from the start helps avoid discussions later on.

Conclusion

The invisible effort behind a TYPO3 website is real, even if it’s difficult to quantify on an invoice. It lies in updates, which have become easier thanks to automation but are by no means superfluous. It lies in the thought process behind every ticket, no matter how small. And it lies in the risks that arise when it is ignored for years.

Once you understand this, you’ll no longer ask, “It’s working fine—why change anything?”

If a specific client who doesn’t understand this came to mind while you were reading, just send them the link to this article. Sometimes that works better than any further conversation.