The Shopify app audit.

What app bloat actually costs

Three separate bills, and founders usually only see the first one.

• Subscription cost. The visible one. It accumulates quietly, because apps are added during projects and rarely removed when the project ends.
• Performance cost. Every app that renders on the storefront ships JavaScript that parses and executes on the same main thread as your theme. This is the main driver of failing Interaction to Next Paint scores, and it is why stores with large stacks tend to feel sluggish on mobile regardless of theme quality.
• Fragility cost. Every app is a third party that can update, break, change pricing or go unmaintained. A stack of twenty apps is twenty vendors whose release schedules you do not control, and it is the reason some stores cannot safely update their theme.

The goal is not a minimal stack for its own sake. An app that reliably makes money is worth its subscription and its milliseconds. The goal is knowing which ones those are.

Build the inventory first

You cannot make decisions against a list you do not have. Pull every installed app from your Shopify admin and record, for each one, six things: what it costs monthly, who asked for it, what job it does, when it was last actually used, whether it renders anything on the storefront, and whether Shopify now does that job natively.

That last column is where most of the savings come from, and the sixth is the one people skip. Two questions make the rest easy: if this app disappeared overnight, what would break, and who would notice? An app nobody can answer that for is not earning its place.

Cross-check the admin list against what actually loads. Open your storefront, look at the network panel and the script tags in your page source, and note every third-party domain. Stores routinely find scripts running from apps that were uninstalled months earlier.

Sort the stack into four buckets

• Keep. It does a job you need, it does it well, and nothing native replaces it. Subscriptions, reviews on a store where reviews drive conversion, your ESP, your helpdesk.
• Consolidate. Three apps doing pieces of one job, which is common with upsells, bundles and popups. One app that covers all three usually costs less than the three combined and ships one bundle instead of three.
• Replace with native or theme code. The biggest single lever, and covered below.
• Remove. Installed for a campaign that ended, a test that concluded, or a founder's idea from two years ago. Delete it, properly.

What Shopify now does natively that stores still pay for

The platform has absorbed a lot of what used to require apps. Before renewing anything, check whether it is already included.

• Discounts, bundles and cart logic. Shopify Functions cover a large share of what discount and bundle apps were built for, and the logic runs on Shopify's side rather than in your customer's browser, which means it costs no frontend performance at all.
• Search and filtering. Search and Discovery handles faceted filtering, synonyms and product boosting for most catalogues, replacing a category of paid apps.
• Forms and custom fields. Metafields and metaobjects cover most custom content and product data needs that used to need an app.
• Markets and currencies. International pricing, domains and currency handling are native.
• Email and automation. Shopify Email and Flow cover basic sends and back-office automation, which is often enough for younger brands.
• B2B and wholesale. Company accounts, catalogues, quantity rules and payment terms replace the customer-tag workarounds and wholesale apps many stores still run, and they are available on all paid plans rather than Plus only. See our Shopify B2B guide.

The honest caveat: native is not always better. A specialist app usually wins on depth. Native usually wins on speed, cost and one fewer vendor. Decide per case, not by policy.

Removing an app properly

This is the step almost everyone gets wrong. Uninstalling an app from the admin removes the app's access. It does not reliably remove the code it added to your storefront, because many apps write directly into your theme during setup.

After uninstalling, check for residue in four places.

• Theme code. Search your theme for the app's name, its vendor domain and its asset filenames. Look in theme.liquid first, then snippets and sections. Orphaned includes and leftover script tags are the norm, not the exception.
• Script tags added through the API. These do not appear in your theme editor at all. They are visible in your rendered page source, and are the usual explanation for a script that keeps loading from a vendor you no longer pay.
• Checkout and additional scripts. Anything left in checkout settings or additional scripts fields.
• Webhooks, metafields and leftover data. Less urgent, but worth clearing so the next person auditing does not chase ghosts.

Do this on a duplicated theme, not your live one. Duplicate, clean, preview, test the paths the app touched, then publish. It is fifteen minutes of care against the risk of taking your cart offline.

Measure before and after

Take the measurement before you touch anything: your field Core Web Vitals from Search Console, your monthly app spend, and a note of which pages feel slow on a real phone. Remove in batches, publish, then wait for field data to catch up before claiming a win. Field metrics are a rolling window, so a same-day lab test proves nothing either way.

What we typically see on a first audit is a meaningful cut in monthly spend and a visible improvement in interaction latency, concentrated on product and collection pages where widget density is highest. The size of both depends entirely on how long the stack has been accumulating.

Make it a cadence, not an event

Stacks regrow. A quarterly review of the app list, plus one rule at install time, keeps it from getting away again: every new app gets an owner, a reason and a review date, and anything that renders on the storefront gets measured before and after installation. If nobody will own it, it does not go on.

Common mistakes

• Uninstalling without cleaning the theme. You keep the performance cost and lose the feature, which is the worst of both.
• Cutting apps that make money to hit an app-count target. The number of apps is not the metric. Cost and milliseconds against contribution is.
• Auditing once and never again. Six months of campaigns and the stack is back.
• Removing everything at once with no rollback. Batch it, publish from a duplicated theme, and keep the previous theme version available until you have watched a full week of orders.

FAQ