TCO Drivers in E-Commerce: What Makes an Online Shop Expensive in the Long Run

Many E-Commerce projects start with a setup that initially seems easy to manage. The shop runs reliably, releases can be implemented without significant effort, and ongoing costs remain within the expected range. It is only during continued operation that it becomes clear how differently technically similar projects can develop. As a result, two shops with comparable project budgets can end up with very different total costs after just a few years.

The reason is that a large share of the Total Cost of Ownership only arises after go-live. We explain why the initial project price provides only an incomplete picture of these long-term costs in the article “TCO in E-Commerce: Why the Project Price Is Only the Beginning” In this article, we look at which factors have the greatest impact on day-to-day operating costs and why their effect increases over time. Technical complexity, shop performance, and hosting quality all play an important role. How strongly these factors affect long-term costs depends to a large extent on the architecture chosen at the beginning of the project.
 

Complexity does not emerge all at once. It grows with every extension and every custom adjustment. In day-to-day operations, this often only becomes noticeable when updates suddenly take longer or ongoing maintenance requires significantly more effort. Indicators include the number of active extensions and the proportion of custom code. Increasing dependencies on external services or ever-longer release cycles are also signs that the setup is becoming more difficult to manage over time.

Every line of custom-written code needs to be maintained in the long term. While standard code is continuously developed within its respective ecosystem and adapted to new versions, responsibility for custom code remains with the internal team or the agency managing the shop.

A high number of active extensions can make maintenance considerably more difficult. What matters is not only the number itself, but also how strongly the extensions interact with one another, whether they are maintained regularly, and how much custom code depends on them. Once a shop uses several dozen extensions, the effort required for testing and coordination during major updates often increases significantly.

Example Scenario: The Update That Took Five Months

The shop has been running on Magento for five years and has grown significantly during that time. It now has 65 active extensions, around 18,000 lines of custom code, and four individually developed modules.

The agency initially estimates six weeks and €60,000 for the major update. After three months, however, only half of the work has been completed because several extensions are incompatible with one another and one of the custom modules needs to be partially redeveloped.

In the end, the update takes five months and costs €168,000. There is no single factor to blame. The setup has become increasingly complex over the years, to the point where even a relatively manageable change now requires a disproportionate amount of effort.

This complexity also generates costs when no new features are being developed. Ongoing maintenance becomes more demanding, troubleshooting takes longer when issues occur, and new employees or agency partners need more time to understand the system. This additional effort remains and continues to increase over the years.

Performance is often viewed primarily as a UX issue, even though it is also a direct economic factor for online shops. The longer a page takes to load, the greater the risk that users will leave the site or abandon their purchase.

A study by Google and Deloitte shows just how much of an impact even small improvements can have. A 0.1-second reduction in load time increased retail conversions by 8.4% (source: Deloitte/Google, 2020).

The real problem usually develops gradually, as a shop becomes slower over a period of months without this being immediately noticeable in day-to-day operations. New scripts are added, images become larger, and additional features increase page weight. If load times are not measured regularly, this development can remain unnoticed for a long time.

Example Scenario: Performance Drift Over 18 Months

A shop with annual revenue of €12 million starts with a mobile load time of 2.1 seconds. Over the following 18 months, it is continuously expanded: new features are added, additional tracking scripts are integrated, and the amount of data transferred increases without load times being reviewed regularly.

After a year and a half, the mobile load time has risen to 4.3 seconds, while the conversion rate has dropped from 2.1% to 1.7%. In the quarterly review, this development is initially attributed to difficult market conditions.

Mathematically, this corresponds to a decline in conversion of around 19%. Depending on the calculation basis, this results in an annual revenue shortfall of between €600,000 and €900,000, even though regular measurements would have made the deterioration visible much earlier.

In practice, declining performance is often initially compensated for by adding more resources. The server is scaled up or the infrastructure is expanded, which may stabilize load times in the short term. However, the underlying cause remains.

As a result, the shop operator may end up paying for additional infrastructure for years, even though the actual problem could lie in the code, an extension, or an external interface. In the worst case, this can mean running 30% to 100% more resources than are actually necessary.
 

At first glance, hosting offers are relatively easy to compare, as both the monthly price and the allocated resources are clearly visible. However, the true differences usually only become apparent during day-to-day operations.

Factors such as how quickly the provider responds to an incident and how reliably the monitoring works play an important role. Are critical changes detected at an early stage, or only once the shop has already slowed down or become unavailable? Over several years, differences like these can result in six-figure costs.

This becomes particularly apparent ahead of seasonal peaks, as simply adding more capacity is often not enough. It should be checked in advance whether the cache configuration is suitable for the expected load and whether the database is properly prepared. At the same time, there needs to be a clear incident-response process so that the team knows who is responsible and when escalation is required.

The value of specialized hosting therefore lies less in individual hardware specifications and more in how well the provider understands the shop and its requirements, and how reliably it supports ongoing operations.

Example Scenario: Black Friday Outage at an Online Fashion Shop

An online fashion shop with annual revenue of €20 million generates around a quarter of its usual monthly revenue on Black Friday alone. During the highest-revenue hour, it generates approximately €15,000 in sales.

If the shop goes down for six hours during this period, the immediate loss in direct revenue amounts to around €90,000. Additional costs arise because customers abandon their purchases and may switch to another provider. At the same time, the technical team is occupied with identifying the cause and restoring operations.

Depending on how the incident unfolds, such an outage can result in total costs of between €150,000 and €250,000. By comparison, the additional cost of specialized managed hosting is often between €20,000 and €60,000 per year. Avoiding just one outage can therefore offset these additional costs over several years.

Independent studies also illustrate how expensive downtime can be for companies. According to ITIC, 98% of surveyed companies estimate the cost of one hour of downtime at more than US$100,000 (source: ITIC, 2024).

The extent to which complexity, performance, and hosting affect ongoing costs depends largely on the chosen architecture. Many of these decisions are made at the beginning of a project and can only be changed later with significant effort. This includes, for example, the choice of frontend, how external systems are integrated, and which hosting model is used.

The frontend plays an important role here. According to the vendor, Hyvä significantly reduces both the number of requests and the amount of data transferred. Agencies also report 20% to 50% less development effort compared with Luma.

This difference does not only affect the initial implementation. Later adjustments and releases also require less time, while new developers can get up to speed with the frontend more quickly. Over several years, these savings can add up to the point where even a larger initial migration investment becomes economically worthwhile.

Case Study: SD Bullion

The US precious metals retailer SD Bullion migrated to Adobe Commerce with the Hyvä Theme. As a result, its mobile performance score increased from 45 to 89, while conversion rates rose by 40% across all categories. At the same time, hosting costs fell by around 35%, while infrastructure costs decreased by approximately 25% (source: Hyvä, 2025).

This example shows that choosing a different frontend affects more than just performance. It can also reduce ongoing infrastructure requirements and, in turn, lower operating costs.
 

Costs become particularly high when the individual cost drivers reinforce one another. As complexity increases, releases take longer, which also makes performance optimizations more difficult to implement. If these improvements are postponed, additional infrastructure is often introduced to compensate for the symptoms in the short term.

Over time, this creates a setup that becomes increasingly difficult and expensive to maintain and develop further. At some point, a fundamental modernization or even replatforming may make more economic sense than continuing with individual adjustments.

Costs therefore rarely increase all at once. Instead, they tend to rise gradually over several years. Many decisions seem reasonable when they are made but become expensive later because they build on an already complex system. A refactoring project that might have cost €20,000 in the second year can cost several times as much in the fifth year under time and growth pressure.

Complexity, performance, and hosting rarely affect operating costs independently of one another. The greatest additional costs usually arise when these factors reinforce each other and the chosen architecture makes future adjustments even more difficult.

Identifying changes early makes it possible to take corrective action in time. This means keeping an eye on increasingly long release cycles as well as rising load times and growing infrastructure requirements. In many cases, problems can be addressed before a comprehensive modernization or replatforming becomes necessary.

Key Metrics You Should Monitor Regularly

• Number of active extensions and proportion of custom code
• Length of release cycles
• Mobile load time and Core Web Vitals
• Conversion rate trends
• Infrastructure requirements in relation to traffic
• Incident response times
  
   

What Drives a Shop’s Operating Costs?

A large share of ongoing costs results from growing complexity, for example due to extensive custom code or a high number of extensions. Declining performance and the quality of hosting also affect TCO over the long term. How significant these factors become depends largely on the architecture chosen at the beginning of the project.

How Can I Identify Growing Complexity?

One of the first warning signs is an increasing number of active extensions. A high proportion of custom code, growing dependencies between extensions, or increasingly long release cycles also indicate that the setup is becoming more difficult to maintain. What matters is not only the number of extensions, but also their quality, compatibility, and the amount of testing required during updates.

What Does Performance Drift Mean?

Performance drift describes the gradual decline in a shop’s performance over several months. New features, additional scripts, or larger images can gradually increase load times. Without regular monitoring, this development often only becomes noticeable once fewer users complete purchases or start abandoning pages.

Why Is Hosting Part of TCO?

When it comes to hosting, the monthly price is only one factor. It is equally important how quickly the provider responds to incidents and whether critical changes are detected early. Especially ahead of traffic peaks, a well-prepared hosting environment can prevent outages and avoid significantly higher follow-up costs.