Shopify technical debt: what do apps and an overloaded theme really cost?

A Shopify app costs 15 to 50 euros a month. Taken on its own, the expense looks harmless. The problem shows up when you add three years of apps installed one after another, never really audited, and never removed once they stop being useful.

How to spot technical debt on your store

Technical debt on Shopify rarely announces itself. It shows up as a store that has become slightly harder to change every quarter. Five signals are usually enough to place where you are:

Apps installed versus apps actually used. Open the installed apps list in the admin and mark the ones nobody has touched in six months. On most stores running for a few years, a third of the list falls in that category.

Your mobile PageSpeed score. Below 50, the accumulation is having a measurable impact on user experience, not just on rankings. Check the product and collection pages, not the homepage: they carry the traffic and they carry the most app scripts.

How often a new idea runs into a theme limit. If the team avoids certain changes because “it’ll be complicated with the current theme”, that’s already an opportunity cost, even if it never appears on an invoice.

Custom code nobody can explain. Snippets added directly to the theme by a previous agency or freelancer, with no documentation, that everyone is now afraid to touch.

Theme updates you keep postponing. A theme several major versions behind is usually a sign that an update once broke something, and that the store has been frozen ever since.

The visible bill

The first cost, the easiest to quantify, is the cumulative monthly subscription total. An e-commerce store active for several years easily accumulates 10 to 15 active apps: reviews, upsell, trust badges, chat, email capture pop-up, image optimisation, SEO, advanced analytics. Each billed separately, often on a plan that has changed (and increased) without anyone noticing.

Over a year, this accumulation commonly adds up to several thousand euros, for features some of which aren’t even actively used anymore. It’s the part everyone looks at first, and it’s the smallest part of the real cost.

What app stacking actually costs

Performance. Every installed app typically injects its own JavaScript, often loading in a blocking way on first render. On its own, one app won’t drastically slow down a site. Stacked on top of each other, they progressively degrade Core Web Vitals with no alert ever triggering: it’s a slow, invisible decline that only becomes obvious once a full PageSpeed audit is run. A site that loads a second slower on mobile loses a measurable share of its visitors before they even see the product. That cost doesn’t appear on any invoice, but it hits revenue directly.

Conversion. Core Web Vitals aren’t just an SEO metric. A checkout that takes longer to load on mobile, a product page showing layout shifts while reviews or a recommendation widget load: these are real points of friction in the buying journey. Mobile conversion is particularly sensitive to this kind of latency, more so than desktop.

Overlap. Stacking also produces duplication that nobody planned. Two apps loading their own jQuery, three tools each firing their own analytics events, an image optimiser fighting with the theme’s own lazy loading. The cost here isn’t just weight, it’s the debugging time when something breaks and no one can tell which tool caused it.

Maintenance and organisation. Harder to measure financially, but real: every added app makes maintenance more complex. A theme update can break compatibility with an app installed two years earlier and never documented. Team turnover means the reason a particular app was installed sometimes gets lost, and nobody wants to remove it for fear of breaking something.

When replacing an app with native code is worth it

The tempting conclusion is to rebuild everything in-house. That’s usually wrong, and expensive in a different way. An app subscription buys you maintenance, compatibility fixes and a roadmap you don’t have to fund. Native code is a one-off cost plus an ongoing responsibility.

Replacing an app with native code makes sense when the feature is simple and stable, when the app’s real job is displaying something you already have (badges, size guides, cross-sell blocks, a countdown), when it’s costing you visibly in performance on high-traffic pages, or when its recurring cost has drifted well past the few days of work it would take to build.

Keep the app when it does genuine ongoing work on your behalf: collecting and moderating reviews, running subscription billing, handling tax or compliance rules that change without warning, or maintaining an integration with an external platform whose API changes on its own schedule. Rebuilding those means signing up to maintain them forever.

Two intermediate options are often the right answer. You can keep the app for its backend and rebuild only the visible part, which removes the script from the critical path without losing the service. Or you can simply remove the app, if the honest answer is that the feature was never doing much.

The decision comes down to one question: is this app doing work, or just rendering? Rendering is cheap to take back. Work isn’t.

Two ways to reduce this debt

The first, short term: an app audit to remove what’s no longer used and replace the heaviest ones with lighter alternatives, without changing the underlying architecture. This is often the highest return per euro spent, and it can be done in days.

The second, medium term once the debt has built up too much: rebuilding the storefront so features are implemented natively instead of bolted on through third-party apps. That can mean a clean Shopify theme redesign, which is the right level for most stores, or a move to headless when the theme itself has become the constraint. The Liquid versus Hydrogen comparison covers where that line sits.

Worth saying plainly: going headless to solve an app problem is an expensive way to do an app audit. Clean the stack first, then judge whether the theme is still what’s holding you back.

If that’s where you are, the Shopify theme redesign path details how the initial audit precisely quantifies this debt before deciding on next steps.