Before you open the Apps page in your Shopify admin, go to Settings, then Billing, then Bills, and download the last twelve invoices. That list is the only honest starting point for a Shopify app audit. The Apps page shows you what is installed; the invoice shows you what you are paying for, and the two are never the same. Every store we look at has at least a few line items nobody on the team can explain. Six is a common number. On a catalogue of any size, one or two of those dead apps are also still injecting JavaScript into every page load, which means you are paying twice: once in dollars, once in LCP.
Why apps go quiet but keep billing
Nobody installs an app they don't need. They install it for a campaign, a theme change, a wholesale experiment, a Diwali sale. Then the campaign ends, the person who set it up moves on, the widget gets pulled out of the theme, and the $29 keeps going out. Shopify has no reason to tell you an app hasn't fired an event in eight months. The app developer certainly doesn't.
The second reason is theme migrations. When you switch themes, app blocks and snippets from the old theme don't come along. The app is still installed, still charging, and now does nothing at all because its snippet lives in a theme you unpublished last March. We find this on almost every store that has changed themes in the last two years.
How to run a Shopify app audit in one afternoon
Three to four hours, one spreadsheet. Columns: app name, monthly charge, billing route, last evidence of use, script weight, native or theme alternative, removal risk, verdict.
- Export the twelve bills and list every recurring app charge, including annual charges that hit once and look small on a monthly view.
- Cross-check your company card statement. A fair number of apps bill outside Shopify, so they never show up on the Shopify invoice at all. Email marketing, helpdesk and some review tools are the usual suspects.
- For each app, find one piece of evidence it did something in the last 30 days.
- Measure what it costs the front end.
- Score, decide, remove in batches of two or three so you can attribute any breakage.
The order matters. If you start from the Apps page you will judge apps on how useful they sound. If you start from the invoice you judge them on what they cost.
Where the usage evidence actually lives
"I think marketing uses it" is not evidence. These are:
- The app's own dashboard. Most show a last-activity date, a sends count, a sessions count or a quota. A heatmap app whose recording quota ran out in February has been decorative since February.
- Your theme files. Search the published theme for the app's snippet name and for its script domain. Also open the JSON templates and check whether its app block is still placed on the product or collection template. If neither is present, the app has no front-end presence, whatever its dashboard claims.
- Settings, Customer events. Pixel-based apps register here. An app with no pixel and no theme block and no admin usage is a subscription, not a tool.
- The live page itself. Open a product page in Chrome, DevTools, Network tab, filter by the app's domain. If nothing loads, nothing is running.
- GA4 or your reporting layer. Upsell, bundle and popup apps that earn their keep produce measurable events and attributable revenue. Ask for the number. If the app has been live nine months and nobody can produce a revenue figure, that is your answer.
One honest caveat: admin-side apps leave the faintest trail. Bulk editors, order taggers, invoice generators and inventory sync tools can be genuinely load-bearing while looking idle from the front end. For those, ask the ops person directly and ask them to show you the last thing they did with it.
Measuring page weight without guessing
Run the product page and the biggest collection page through PageSpeed Insights, then do the real work in DevTools. Network tab, disable cache, throttle to Slow 4G, sort by transfer size, and note every third-party script with its domain. Then open the Coverage panel and reload. It tells you how much of each script was never executed on that page.
The pattern we see on mid-size apparel and beauty catalogues: eight to twelve third-party scripts on the product template, 300 to 500KB of JavaScript between them, and Coverage showing 80 to 90 percent of it unused on that page type. A review app loading its full bundle on a page with four reviews. A currency switcher loading on a store that sells in one currency. Trimming that set is usually worth several hundred milliseconds of mobile LCP, more if the scripts are blocking. If you want the scan repeated automatically after the cleanup rather than remembered as a one-off, our SwiftStore app monitors the score over time and fixes some of the common regressions; the deeper theme-level work is what we cover under Shopify speed optimization.
Score sheet: four numbers per app
Score each app 0 to 3 on four axes. Low is good.
- Cost. 0 = free, 1 = under $20, 2 = $20 to $60, 3 = above $60 or usage-billed with a rising trend.
- Front-end weight. 0 = admin only, no storefront script. 1 = under 50KB. 2 = 50 to 150KB. 3 = above 150KB or render-blocking.
- Evidence of use. 0 = daily, with a number attached. 1 = weekly. 2 = one instance in the last quarter. 3 = none found.
- Replaceability. 0 = nothing native or thematic comes close. 3 = Shopify or your theme already does it.
Total of 9 or more: remove, unless someone can defend it in one sentence. 6 to 8: put it on notice with a named owner and a review date. 5 or below: keep and stop thinking about it.
The scoring is crude on purpose. Anything more elaborate turns into a project and never gets finished.
The six that usually fall out
Different stores, remarkably similar kill list.
- A second review app, installed during a theme change while the first one was still active.
- An upsell or bundle app whose widget was pulled out of the theme months ago. Subscription live, block gone.
- A popup or trust-badge app that was for one campaign.
- A heatmap or session-recording tool nobody has logged into since the quota expired.
- A page builder bought for a single landing page, now the heaviest script on the site.
- A currency converter or a country-redirect app doing what Shopify Markets does natively.
Add to that list anything that duplicates a function: two SEO apps, two bulk editors, a metafield app plus a metaobject setup you built later. Duplication is the cheapest thing to cut because nothing breaks.
The arithmetic, on a real-shaped example
Take a store with 19 apps and a Shopify app bill around $560 a month. The audit flags six for removal: $19, $29, $49, $14, $39 and $24. That is $174 a month, $2,088 a year. At ₹85 to the dollar that is about ₹1,77,000 a year, before the cross-border markup Indian cards usually add on foreign-currency charges. Check with your CA on how the GST treatment applies to your registration, because it changes what the real cost is.
The four with storefront scripts accounted for roughly 210KB of JavaScript on the product template. Removing them, properly, took mobile LCP from about 3.1s to 2.4s on a mid-range Android over throttled 4G. Neither number alone would get budget approval. Together they make the afternoon obviously worth it.
Uninstalling is not the same as removing
This is where app audits go wrong, and where we get it wrong ourselves on the first pass maybe a third of the time. Clicking Delete stops the billing. It does not always clean the theme.
- Orphan snippets and script tags. Older apps write directly into theme.liquid or product templates. When the app is gone, the include stays, and you get either a Liquid error or a request to a dead domain on every page load. Search the theme for the app's name after uninstalling.
- Your data leaves with it. Reviews live with the review app. Export the CSV first, confirm the import path into whatever replaces it, then uninstall. Same for loyalty balances and subscription contracts, and subscriptions in particular are not a same-day job.
- Metafields and metaobjects stay behind. Usually harmless, occasionally referenced by another app or by your own theme code. Check before you bulk-delete them.
- Checkout customisations. If anything you are removing touched checkout, verify the flow end to end on a real transaction, including COD and your Razorpay or PayU path. Checkout extensibility changed how this works and old assumptions do not carry over.
- Multi-location stores. Inventory sync, fulfilment and shipping-rate apps that look idle from the storefront are often the only thing making a second warehouse work. Confirm with the person who packs the orders, not with the dashboard.
Remove two or three at a time, then place a test order the same day. If something breaks a week later you will know which batch to look at.
Keep the expensive ones that earn
An audit that only cuts is a bad audit. Some of the heaviest, priciest apps are the best value on the store. Search and filtering on a 3,000-SKU catalogue, a well-implemented reviews setup, your email platform: these carry real revenue and the invoice line is not the interesting number. What matters is whether anyone can tell you what the app returned last month. If they can, stop auditing it.
The opposite case is worth naming too. Occasionally the right outcome is to stop paying three apps $40 each to half-solve one problem and have the thing built into the theme properly instead. That is not always cheaper in year one. It is usually cheaper by year two, and it is always lighter. We size that trade-off in custom Shopify app and feature work often enough to say the break-even is normally somewhere between 14 and 24 months.
Make it quarterly, and give every app an owner
The fix that actually holds: a column in the spreadsheet with a person's name against every app, and a rule that installing an app requires a removal date or a named owner. Review the list at the end of each quarter, and always before the festive build-up, because September is a terrible month to discover that a page builder you forgot about is adding 400ms to every product page.
If you would rather not do the DevTools part yourself, send us the store URL and we will run the app and speed side of it as a free store audit, with the script weights and the kill list written out so you can act on it without us.