Most stores can name what each app costs per month. Far fewer can name what it costs in page weight, duplicated data and the mornings lost to figuring out which app broke something. Here is how to audit a stack properly.
App stacks grow the way household clutter does: one reasonable decision at a time. A review app in month one, a bundles app for a campaign, an upsell app someone recommended, a second analytics tool because the first one disagreed with Shopify. Nobody ever decides to run twenty apps. You just arrive there.
The monthly bill is the part everyone sees, and it is usually the smallest part of the cost.
The four costs that never appear on the invoice
- Page weight. Apps that inject storefront scripts add to what every visitor downloads and executes. A script that runs on every page to power a feature used on two pages is pure tax.
- Duplicated truth. Two apps counting the same event will disagree, because they define the event differently. Once you have two numbers you trust neither, and decisions slow down.
- Blast radius. The more apps that write to the same objects — products, collections, metafields, themes — the harder it is to answer 'what changed?' when something looks wrong.
- Your attention. Every app is a login, a billing line, a settings page, an update that might break, and a support queue to chase when it does.
A stack audit you can do in an afternoon
Open your app list and put every app into one of four buckets. Be unsentimental; the point is to make the quiet costs visible.
- Earning. You can name the outcome it produces and point at where you see it. Keep.
- Insurance. It does nothing most days but matters when something goes wrong — backups, monitoring. Keep, but check it actually works.
- Sentimental. It was useful once, for a campaign or a founder's experiment, and nobody has turned it off. Uninstall.
- Unknown. Nobody currently at the company knows why it is installed. Investigate, then uninstall.
Then ask the harder question of the Earning bucket: does this app add storefront JavaScript, and does it need to? An app that does its work server-side, or through Shopify's own data, costs your customers nothing to load.
Why we built SellRank to add nothing to your storefront
Collection sorting is a good example of a job that does not need to be done in the shopper's browser. SellRank computes the order on our servers and writes it into Shopify's own manual sort order — the same field you would set by dragging products in admin. Your theme renders the collection exactly as it always did. There is no sorting script, no layout shift while products rearrange, and nothing to remove from theme.liquid if you uninstall.
The one piece that does run on the storefront is a web pixel counting product views and add-to-carts, and Shopify sandboxes that. It exists because ranking by real demand needs demand data, and we would rather collect it ourselves than ask every merchant to configure Google Analytics correctly.
The uninstall test
Before you add an app, ask what happens when you remove it. An app that leaves broken markup, orphaned metafields or a theme you cannot safely update has effectively taken a deposit you will pay to get back. An app that leaves your store exactly as it found it is one you can try without fear.
That test is worth applying to any app you are evaluating, including ours. Uninstall SellRank and your collections keep the last order that was pushed, sitting on manual sort, until you change it in Shopify admin. Nothing breaks, because nothing was ever grafted on.
Fewer, better, measured
The goal is not a minimal stack for its own sake. It is a stack where you can name what each piece does, see the result, and remove any one of them without a rescue project. Most stores are two or three uninstalls away from a store that loads faster and a team that argues less about which number is right.
