Shopify App Dependency Hell: The Pre-Install Audit We Run on Every New App

The Install Button Is a Contract You Cannot Read

Every Shopify app install is a silent contract. The merchant clicks Add app, approves a scope list nobody reads, and agrees to let a third party touch the storefront, the admin, the checkout, the customer record, and in many cases the theme source itself. There is no diff, no preview, no itemised impact summary. The consequences show up weeks later, usually as a slow LCP, a checkout that silently fails on one market, or an uninstall that leaves orphan liquid in the theme and dead webhooks in Settings.

After auditing more than two hundred and fifty Shopify stores, almost every unexplained performance drop, every broken checkout extension, and every bloated theme we have inherited traces back to one thing: the merchant installed an app without running a pre-install audit. The App Store's star ratings and review counts are not a filter. They are a marketing surface. What is missing is a short technical interview you put every candidate app through before Add app gets clicked. This article is the interview we use on every client store.

What The Shopify App Store Review Count Is Not Telling You

The App Store's social proof is heavily biased by review velocity, install campaigns, and prompted reviews from merchants who have not yet felt the app's long-term consequences. An app with ten thousand reviews accumulated over eight years, from a developer with three narrow-focus apps and a Built for Shopify badge, is a very different risk profile from an app with eight thousand reviews in eighteen months off the back of an aggressive install-for-discount campaign. Total count is almost useless. Review velocity, weighted against how long the app has been live, is the number to look at.

The signal inside the reviews is more useful than the aggregate score. Sort one-star reviews by most recent and scan for date clusters. A spike of one-stars on the same week almost always follows a bad release, and the question is whether the developer's responses are substantive or templated requests to email support. Look at the publisher's partner page, not just the app page. A developer with fifteen apps spanning reviews, subscriptions, wishlists, bundles, upsells, and SMS is a portfolio operator optimising for install funnels. A developer with one or two apps and five years on the platform is usually building a product. Built for Shopify is a meaningful badge because it enforces specific performance, merchant UX, privacy, and API compliance criteria, and it is revoked when an app falls out of conformance. Plain "Shopify-verified" status only means the app passed initial review.

Read the app's changelog before the reviews. A changelog that shows regular, small, dated releases reflects an engineering culture. A silence of six months followed by a major version bump usually explains the one-star cluster that comes next.

Question One: Who Built This And How Long Have They Been Here

We want a long-tenured, narrow-focus developer with an identifiable team presence, a public documentation site, and ideally a Built for Shopify badge on the app in question. Check their partner profile for total app count, average star rating across the portfolio, and support response rate. Check whether the developer publishes a status page, a changelog, and release notes, and whether their privacy policy enumerates the Shopify GDPR webhooks they handle, specifically customers/data_request, customers/redact, and shop/redact. An app that cannot articulate how it responds to a data redaction request is not ready to touch a customer record.

This question goes first because the publisher's posture determines everything else. A publisher who takes script loading seriously, ships uninstall cleanup, migrates early to new Shopify surfaces, and documents their API produces an app that ages well. A publisher who does not will produce an app that slowly fails the other five questions.

Question Two: How Does The App Load On The Storefront

This is the question that matters most for performance and the question that almost nobody asks. Shopify apps can put code in front of your customers through four mechanisms, and the mechanism determines whether the app will cost you Largest Contentful Paint, Interaction to Next Paint, and ultimately revenue.

The first is App Embeds, a type of Theme App Extension where the merchant toggles an embed block in the theme editor under App embeds. The script loads through a block the merchant controls, typically with defer or async, and the theme source is never modified. The second is Theme App Extensions as section blocks, where the merchant drags an app block into a section. Both are clean, versioned with the app, and remove themselves on uninstall. The third is the legacy ScriptTag API, which injects a <script src> tag into the storefront on every page without merchant control. Many older review, loyalty, and popup apps still use ScriptTag. The fourth and worst is direct asset injection, where the app writes liquid snippets into your theme files at install. This is the mechanism that creates orphan code.

To audit this, install the app on a development store, open Chrome DevTools, and filter the Network panel by the app's vendor domain. Look at whether the script has defer or async, whether it is render-blocking, where in the document it is injected, and its byte weight over the wire. Run a Lighthouse pass against a product page before and after install. An app that adds two hundred kilobytes of blocking JavaScript to every page load, through ScriptTag rather than App Embeds with defer, is a tax that compounds for every customer who loads your site. An app that loads through an App Embed with defer, declares a single specific route, and ships under fifty kilobytes is doing its job. This difference does not appear in the App Store listing. You have to measure it.

Question Three: What Happens When You Uninstall

The Shopify App Store tells you what an app does on install. It does not tell you what it leaves behind on uninstall, and this is where dependency hell actually lives. An app that cannot be cleanly removed is a permanent house guest. Every store we inherit from a previous agency or from a merchant who has been on Shopify for more than three years carries orphan liquid in theme.liquid, orphan snippets in snippets/, stranded webhook subscriptions, stranded metafield definitions, and stranded script tags from apps that were uninstalled years ago.

The uninstall hygiene test takes twenty minutes and saves years of cleanup. Pull the theme locally with shopify theme pull and commit it to a local branch. Install the app. Re-pull and diff. You will see exactly which theme files the app touched, whether it added snippets, whether it edited theme.liquid or layout/*.liquid, and whether it registered any assets. Uninstall the app. Re-pull and diff again. Anything that remains is orphan code you will carry on every deploy until somebody removes it by hand. Then open Settings, Notifications, Webhooks, and Apps and sales channels, and confirm nothing is stranded. App-level webhooks are supposed to be removed on uninstall, but merchant-registered webhooks and metafield definitions often are not.

A good app touches nothing outside its own extension surface, adds exactly the liquid it needs through a Theme App Extension, and disappears completely on uninstall. A bad app writes into your theme and leaves graffiti behind. The App Store listing cannot answer this question. You have to install on a dev store and watch.

Question Four: Is This App Actually On Checkout Extensibility

For any app that touches the checkout, upsell, shipping, payment, or order confirmation surfaces, there is only one version of this question that matters. Is the app built on Checkout Extensibility, meaning Checkout UI Extensions running in Shopify's sandboxed runtime, or is it still dependent on the legacy checkout.liquid template? Shopify has sunset checkout.liquid for the Information, Shipping, and Payment pages for all merchants, and for the Thank You and Order Status pages on Plus. Apps that still rely on checkout.liquid injections stop working on those surfaces. This is a hard deadline the platform has already enforced, and any app still marketing checkout.liquid integrations in its onboarding docs is an app whose roadmap is behind.

Search the app's documentation for "checkout extensibility," "Checkout UI Extensions," shopify.extension.toml, and an api_version of 2024-07 or newer. Check whether the listing mentions "Works with Shopify's new checkout" or lists explicit extension targets like purchase.checkout.block.render. For upsell apps in particular, the split is stark. Some publishers migrated two years ago and have mature extensions. Others will force you to redo the integration when they eventually catch up. The cost of choosing correctly is zero.

The same principle applies to New Customer Accounts and Shopify Markets. If the merchant is running multi-currency or multi-domain through Markets, any app that hardcodes /collections/all, assumes a single currency, or cannot scope its logic by market will produce wrong prices or broken links for some customers. If the merchant is on New Customer Accounts rather than Classic, any loyalty, wishlist, or subscription app that only ships a Classic account widget will be invisible. Ask the publisher which extension targets they support. If the answer is vague, the answer is no.

Question Five: Can You Get Your Data Back Out

The final technical question is the one that determines whether the app is a tool or a trap. Every app that accumulates merchant data, and that is most of them, needs a portability story. The test is simple. Can you export the app's data as a CSV, by yourself, without filing a support ticket? Is there an Admin API or GraphQL endpoint that lists the app's resources in a documented shape? Does the app write to Shopify-native primitives where they exist, such as Subscription Contracts, Metafields, Customer Segments, and Discount Codes, or does it keep everything in a vendor-only silo that leaves with the app if you uninstall?

Reviews apps are a good test case. A review app that lets you export every review with the product handle, customer email, media URLs, timestamps, and verified-buyer status is an app you can leave. A review app where the only way to get your reviews out is to email support and wait three days is an app that owns your social proof. Subscription apps are the same. A subscription app built on Shopify's native Subscription Contracts API stores data in a place you can migrate. A subscription app that keeps contract state in its own database, with no public API to read it, is vendor lock-in designed to make switching prohibitive.

Ask the vendor for migration documentation before you sign up, not after. If a migration-out guide is linked from the public docs, the publisher is competing on value rather than switching cost. If no such guide exists, you have your answer. This is where the GDPR webhook check closes the loop. An app that honors customers/redact and shop/redact is an app that knows how to delete its own data, which is a prerequisite for knowing how to export it.

Question Six: Does The Total Cost Of This App Earn Its Place On The Store

Every installed app has a total cost that is the sum of the monthly subscription fee, the LCP cost on every page load, the INP cost on every interaction, the developer time to integrate with the rest of the stack, the switching cost when it stops fitting, and the audit cost of everything it touches. A hundred-dollar popup app that adds a hundred and fifty kilobytes of JavaScript to every page, loads through a legacy ScriptTag, leaves orphan liquid on uninstall, does not work with checkout extensibility, and has no CSV export is not a hundred-dollar app. It is a hundred-dollar app plus a revenue leak on core web vitals plus an eventual remediation project.

Before installing, ask whether the feature could be delivered with a metafield plus a section block, a Shopify Flow trigger, a Shopify Function for discounts or delivery customisation, or a simple Theme App Extension you build once. Many apps on a typical Shopify stack are compensating for features the platform now offers natively, and removing them in favour of native primitives is almost always a net win.

The Filter In Practice

Running all six questions on a candidate app takes about forty-five minutes. Twenty minutes on the publisher, the reviews, the changelog, and the privacy policy. Twenty minutes on a development store install, a theme diff, a Network panel audit, and an uninstall diff. Five minutes on data portability and checkout extensibility confirmation. Compare that to discovering the problems three months later on production, after the team has built workflows around the app and you have to unpick it without breaking anything.

A good app passes all six questions visibly. A mediocre app passes three or four and requires compensating controls. A bad app fails two or more and should be rejected, no matter how compelling the demo or aggressive the promotional deal. The merchants we see with clean, fast, maintainable stacks are not the ones who found better apps. They are the ones who said no more often.

How WitsCode Runs The Pre-Install Audit For Clients

On every managed client store, no app reaches production without running through this six-question filter. We maintain a development store for every client, pull the theme with source control, run the install and uninstall diffs, and audit the script loading through DevTools and Lighthouse before anyone clicks Add app on the live store. For merchants evaluating a stack rebuild, a platform migration, or a specific app category where the choice matters, we offer the pre-install audit as a standalone engagement. You send us the shortlist. We run the filter. You get a ranked report with the script loading profile, uninstall diff, checkout extensibility status, data portability assessment, and a recommendation for each candidate, before you commit. Most merchants recoup the cost on the first app they choose not to install. Reach out to WitsCode and we will run the filter on your shortlist.