Auditing your Shopify app stack before it eats your margins
The average store we audit runs 20-plus apps. Here is how we decide which to keep, replace with native features or rebuild.

Apps are how most Shopify stores grow, and also how most of them slow down. Each app solves a real problem when it is installed. Two years later the store runs 25 of them, several overlap, a few are no longer used, and the monthly bill has crept past what a small custom build would have cost. Worse, many apps inject scripts into every page whether or not they are needed there. When a client asks us why their store feels heavy, the app stack is the first place we look. This is the audit process we run.
Step one: build the inventory
Start with the list in the admin, then go further. For every app, we record:
- Monthly cost, including usage-based fees that do not show on the pricing page.
- Owner inside the business, meaning the person who would notice if it disappeared.
- What it touches: theme app blocks, app embeds, checkout extensions, script tags, webhooks or data sync.
- Page weight it adds, measured by loading key templates with and without it.
- Date of last meaningful use, taken from the app's own reports or the owner's memory.
The owner column is the most revealing. On a typical audit, three or four apps have no owner at all. Nobody remembers installing them, and nobody can say what would break if they were removed. Those go straight to the review pile.
Step two: measure the real cost
Subscription fees are the visible cost. The invisible costs are usually larger. We measure each app's impact on the templates that matter: home, collection, product and cart. Using a lab test with a throttled mobile profile, we compare total blocking time and page weight with the app's embed turned off. It is common to find a single reviews or personalization app adding 200 to 400 KB of JavaScript to every page, including pages where its widget never renders.
We then translate that into money. If a store converts at 2.5 percent, and our field data suggests the product page's interaction delay is costing even a tenth of a point of conversion, the app's real price is several times its subscription. Framing it this way makes the conversation with stakeholders much shorter.
The monthly invoice is the cheapest part of most apps. The expensive part is the JavaScript your customers download on every page.
Step three: sort every app into one of four decisions
- Keep. The app does something valuable, has an owner and behaves well. Reviews, subscriptions and ERP connectors often land here.
- Replace with native. Shopify has absorbed a remarkable number of features that used to require apps: product bundles, metafield-driven content, search and discovery filters, basic B2B pricing, customer accounts, forms and translation. If the native version covers 80 percent of what you use, it usually wins.
- Rebuild as theme code or a custom app. Small features such as size guides, countdown timers, announcement bars and free-shipping progress bars are a few dozen lines of Liquid and JavaScript. Owning them removes a subscription and a script.
- Remove. No owner, no measurable use, or a duplicate of another app.
On a recent audit for a home goods brand, 27 apps became 14. Monthly app spend fell by a little over 60 percent, and median product page JavaScript dropped by roughly half. None of the removed functionality was missed.
Step four: uninstall properly
Uninstalling an app from the admin does not always remove what it left behind. Older apps in particular inserted snippets directly into theme files, created hidden metafields, or registered script tags that persist. After every removal we:
- Search the theme for the app's name, domain and snippet includes, and remove orphaned references.
- Check the page source for scripts still loading from the app's CDN.
- Review metafield definitions and remove namespaces the app no longer uses.
- Confirm that no webhooks or flows still point at the app's endpoints.
Data is the other thing to plan for before uninstalling. Reviews, loyalty balances, subscription contracts and wishlist data often live in the app's own database. Export them, confirm the replacement can import them, and schedule the switch so customers never see an empty reviews widget or a zeroed points balance.
We make these removals on a duplicate theme first and compare the rendered output of each template against the live theme. It is slow, careful work, and it is the part that actually recovers performance.
Keeping the stack lean afterwards
The audit is only useful if the store does not drift back. We leave clients with a simple policy: every new app needs an owner, a stated purpose and a review date six months out. Apps that use theme app extensions and load their scripts only on templates where their block appears are preferred over those that inject globally. And before installing anything, someone checks whether Shopify now does it natively.
When the right answer is a custom build, our Shopify app development team builds private apps that do exactly one job well and that the client owns outright. Theme-level replacements are part of our store speed tuning engagements, where the goal is a measurable improvement in Core Web Vitals, not just a lighter invoice. For stores that want the whole foundation reset, a new custom Shopify theme built around native features is often the cleanest path.
Find out what your apps are really costing you
If your app list has grown past the point where anyone can explain it, we can run the audit for you and hand back a prioritized plan. Get in touch and we will send a fixed-price quote within 24 hours.



