What's the Real Annual Cost of My Shopify App Stack?

If you add up the monthly subscription line on every installed app, you'll see one number. That number is incomplete. The subscription total materially understates the full cost of running your app stack. The real cost includes three things that don't appear on the billing page: the surface area cost (a framing I'll define in a moment), the migration cost, and the compounding cost of subscriptions that never go away.

I'll show you how to calculate the actual number, and why the OpEx side of app bloat is the conversation that finally gets the CFO's attention.

What does "renting features" actually mean on Shopify?

Every installed app is a rental agreement. You pay monthly for functionality the app provides. As long as the rent is paid, the functionality keeps working. The moment you stop paying, you lose access. This is fine, it's how SaaS has worked for two decades.

What's specific to Shopify is the number of rentals one store accumulates. Across the $5M–$100M Shopify Plus stores I've personally audited, install counts land between roughly 18 and 45 apps: reviews, loyalty, subscriptions, popups, A/B testing, search, recommendations, returns, accounting sync, inventory sync, fraud, tax, shipping calculators, page builders, customizers, and on and on. That range is my own audit sample, not a published industry benchmark. Your store may sit outside it in either direction.

Each rental was a reasonable decision at the time. The problem isn't any one app. It's that the rental agreements don't have a natural expiration date. They keep auto-renewing whether or not the feature is still pulling weight. And the rent goes up.

This is the OpEx side of app bloat. It's a different conversation from the performance side, different stakeholders, different math, different fix. But it's the conversation that usually unlocks the budget for the performance work.

Why doesn't this look like a big number on any single month?

The single-month view is the trap.

Look at one month of app billing in isolation and you'll see a list of charges that mostly run $10–$300 each. A $49/month app feels modest. A $199/month app feels reasonable for what it does. A $14/month utility app barely registers.

Now look at the same list across twelve months. The $49/month app is $588/year. The $199/month app is $2,388/year. The $14/month utility is $168/year, and you have eight of those.

Now look at the same list across thirty-six months. A multi-year view is where the true spend actually shows up; the longer you hold the rentals, the more conspicuous the running total. The $49/month app you forgot about is $1,764. The $199/month app is $7,164. The eight $14/month utilities are $4,032.

The month-by-month review never triggers concern because no single line item is large enough to question. The annual review usually doesn't happen because nobody owns it. By the time someone runs the 36-month view, you're looking at a serious number in subscription costs for features that may or may not be earning their rent.

What's the math that no one runs?

The math is simple. Multiply the monthly subscription by 36. That's the three-year cost of keeping the app installed. If you're not confident the app produced more than that in revenue, traffic, conversion, or operational savings, the rental isn't earning out.

Try this for one app you suspect is borderline:

• Monthly cost × 12 = annual cost
• Annual cost × 3 = three-year cost
• Three-year cost ÷ store's average order value = number of additional orders the app needs to drive just to break even

For a $199/month app on a store with an $80 AOV, you need roughly 90 additional orders attributable to that app over three years just to break even on subscription cost alone, and that ignores margin. On a 40% gross margin product, you need closer to 225 additional orders to actually break even on contribution.

The reason no one runs this math isn't that it's hard. It's that nobody owns it. Marketing owns the loyalty app. Customer service owns the helpdesk. Operations owns the inventory sync. Each owner sees their own line item as reasonable. Nobody sees the total.

What's the surface area cost on top of the subscription?

The subscription is the obvious cost. What I call the surface area cost is the one that doesn't appear anywhere; it's my own framing for the technical-debt side of carrying a heavy app stack, not an established industry metric.

Every app that injects code into your storefront adds load time, request count, and main-thread work. That cost shows up in three places: lost conversions from slower pages, weaker Core Web Vitals scores against Google's current thresholds (which I cover in the calculation section below), and engineering hours spent debugging issues caused by app conflicts.

On one engagement with a global crafting supplier, I removed 194 HTTP requests from a single page by cleaning up app bloat and the ghost code left behind by previous app removals. On a separate engagement with a consumer electronics retailer, the same kind of cleanup cut load time by 96%. Both numbers are from my own published results. Neither store had a line item on their P&L called "cost of app surface area." Both stores were paying it daily in lost performance.

The surface area cost is real but invisible. It's why the OpEx conversation usually starts with the subscription line ("we're paying how much for this stack?") and ends with the performance line ("…and it's also costing us conversion rate?"). Both costs trace back to the same root cause.

What's the migration cost when you finally remove an app?

This is the one that surprises people. Removing an app isn't free.

A simple app like a popup tool or a free shipping bar uninstalls cleanly in five minutes. The theme code is shallow, the data is stateless, and nobody depended on it for anything operational.

A deeply integrated app, a subscription engine, a loyalty program, and a custom checkout flow do not uninstall cleanly. Shopify's own community guidance points merchants to manual code review and developer help for leftover code after an uninstall, because uninstalling does not automatically remove theme code, script tags, asset uploads, or webhooks the app added during install. You're looking at theme code removal, data migration to whatever replaces it (or to native Shopify if available), historical record reconciliation, customer communication if anything customer-facing changes, and a fallback plan if the replacement underperforms.

The longer an app has been installed, the more expensive it is to remove. That's the twist with app rentals: the longer you rent, the more you're locked in. A subscription app installed three years ago has touched your customer data, your reporting, your checkout, and your support flows. Removing it is a project, not a settings change.

This is why the OpEx side compounds. You'd remove the app if it were free to remove. It isn't. So you keep paying the rent. And the rent keeps going up.

Why does this hit the P&L harder than expected?

Three reasons.

First, app costs hit operating expenses, not cost of goods sold. They show up as recurring monthly software charges in your tech stack line. That line is rarely scrutinized at the same level as ad spend or fulfillment because it's smaller in absolute terms, until you actually add it up.

Second, app costs don't scale with revenue the way COGS does. If your revenue drops 20% in a quarter, your app subscriptions don't drop with it. They stay flat or grow. The OpEx becomes a higher percentage of revenue in down quarters, which is exactly when nobody wants to see a fixed cost line growing as a share of revenue.

Third, app subscriptions compound with team familiarity. Every app you keep is another tool your team needs to know. The longer it's there, the more workflows depend on it. The more workflows depend on it, the harder it is to remove. The harder it is to remove, the longer the subscription continues. This is the "renting forever" outcome that every Shopify Plus operator wants to avoid and most land in anyway.

For the wider picture of how this connects to performance loss, ghost code, and the technical-debt side of app bloat, I keep my full app bloat guide updated as the central resource. 

How do I actually calculate my true annual app cost?

There's a five-line calculation that gives you a credible number.

Line 1 — Sum of all installed app monthly subscriptions × 12. This is the visible cost.

Line 2 — Estimate the monthly cost of apps you've installed but no longer use. The audit approach I cover separately surfaces these. Multiply by 12.

Line 3 — Estimate the engineering hours spent in the past year debugging app-related issues, integrating apps, or removing app code. Multiply by your blended hourly engineering cost.

Line 4 — Estimate the conversion impact of app-driven load time. This is the hardest line to estimate without specific testing. I'm not going to give you a universal millisecond-to-revenue ratio, because there isn't a credible current one to give. Google's performance guidance is built around Core Web Vitals thresholds, not a fixed conversion-per-millisecond figure. Those thresholds are LCP at 2.5 seconds or below, INP at 200 milliseconds or below, and CLS at 0.1 or below, measured at the 75th percentile of real-user loads. The right way to estimate this line for your store is to run PageSpeed Insights before and after blocking a representative app's scripts, then check which side of each CWV threshold you fall on. If your apps are pushing you above the thresholds, you have a measurable conversion risk worth quantifying with a proper measurement project.

Line 5 — Sum lines 1 through 4. This is closer to your true annual app cost.

For most $5M–$100M Plus stores I've worked with, the visible cost (Line 1) ends up being a fraction of the true cost (Line 5). The exact ratio varies enough across stores that I don't publish a universal number. It depends on how deep the bloat runs, how much engineering time is being absorbed, and where the store sits relative to the Core Web Vitals thresholds.

What would I do if I were running this calculation for the first time?

Three things, in order.

First, run the audit I covered separately and get the 30-minute triage list. You can't calculate true cost on a stack you can't see clearly.

Second, run the five-line calculation above on your existing stack with no removals applied. This is your baseline. Print the number. Show it to your CFO. Ask whether anyone has seen this number before. Almost certainly nobody has.

Third, pick the three apps with the worst rent-to-value ratio — high subscription, high surface area, low or unknown business contribution. These are your candidates for the deeper removal review. Don't try to remove them in the audit step. Just identify them as the candidates worth a proper conversation.

The OpEx side isn't usually solved by cutting all 30 apps. It's solved by cutting the three or four that are eating the most rent without producing proportional value, while keeping the ones that are quietly load-bearing.

What's the difference between this view and a normal SaaS spend review?

A normal SaaS spend review looks at every tool the business uses: billing software, project management, communication, CRM. App bloat is specific to Shopify because the apps live inside the storefront, not in the back office. They affect customer experience directly. They affect performance directly. They affect conversion directly.

A SaaS spend review treats every tool the same. An app review weighs the customer-facing apps more heavily because their cost includes performance and conversion impact, not just subscription. This is why a SaaS spend review will catch some of the bloat but not all of it. The OpEx side gets surfaced. The surface area side doesn't.

If your finance team has done a SaaS spend review but never specifically reviewed your Shopify app stack with performance and surface area in scope, the app review is still to come.

If you want a second pass on the math

If you've run the calculation and want a second set of eyes, particularly on Line 4 (the conversion impact estimate), I'm happy to take a look. I'll send back the same calculation with my own assumptions and a comparison.