The app audit: what every installed app costs you

Most app audits begin and end in the billing screen. Somebody totals the monthly subscriptions, finds a number larger than expected, and cancels the three cheapest things nobody recognises. That is not an audit, it is a tidy-up, and it reliably leaves the expensive problems in place while removing something the warehouse was using.

The fee understates the cost in one direction and overstates it in another. Understates, because an app that reads every customer record, injects three scripts and underpins a Flow nobody documented is carrying risk that has no price on it. Overstates, because the £39 app doing one job reliably is the best value on the store and gets cancelled for being legible.

So record four things per app, and do it in a spreadsheet rather than in a meeting. Cost. Data. Surface. Dependency. The verdict column fills itself in once those four are honest.

This is where an app audit stops being housekeeping. Shopify operates a tiered model for customer data access, and it is documented plainly enough to audit against. Level 0 is no customer data at all. Level 1 covers protected customer data excluding the directly identifying fields. Level 2 adds them: name, address, email and phone. Shopify's stated standard for approval is that the requested data is "the minimum amount required by your app" to function.

Two consequences worth sitting with.

The first is that public apps go through review to reach levels 1 and 2, and custom apps are shown in Shopify's own table as always having that access. If a developer built you something three years ago that reads orders, it has the reach of a level 2 app and none of the review. That is not an argument against custom apps — we build them — but it is an argument for knowing which ones exist and what they query.

The second is the uninstall question, and the answer is not comforting. Shopify's privacy compliance documentation states that "48 hours after a store owner uninstalls your app, Shopify sends a payload on the shop/redact topic", which asks the vendor to erase all data for that store. The obligation is real and apps must respond within 30 days. What you have is an obligation, not a confirmation. There is no receipt, and nothing in your admin tells you whether a vendor you sacked in March still holds your customer list.

The same documentation sets out the customer-level timing, and it surprises people: on a customers/redact request Shopify "sends the payload 10 days after the deletion request" where the customer has not ordered in six months, and otherwise withholds it until six months have passed. If your privacy policy promises deletion faster than that, the promise is not one your app estate can keep. That is worth knowing before somebody asks rather than during the asking.

An app touches your storefront in one of three ways, and they behave completely differently at removal.

A theme app extension is the modern arrangement. The app's blocks and embeds live in the app, not in your theme, so uninstalling genuinely removes them. Nothing to clean up.

A script tag is the old arrangement. Shopify now states that "Script tags can only be used with vintage themes", and that an app integrating with a theme and intending to be listed "must use theme app extensions instead of Script tags". Combined with the REST Admin API being legacy as of 1 October 2024 and new public apps required to be GraphQL-only from 1 April 2025, an app still working this way is telling you something about its maintenance, and that is the useful finding — not the script tag itself.

Hardcoded Liquid is the one that costs you. Somebody pasted a snippet into theme.liquid to make an app work, the app left, and the snippet stayed. Every theme we audit has some. They are usually harmless and occasionally not: a fetch to a domain that no longer resolves, a stylesheet that still loads, a container div holding space for a widget that will never render.

The test for each is the same and takes a minute: disable the app embed or comment the snippet on a theme copy, and look at the page. If nothing changes, you have found dead weight. Keep a note of what you removed and when — the one time this bites is a seasonal feature that only renders in November.

The riskiest app on most stores is not the slowest or the most expensive. It is the one whose output somebody downstream depends on without either of them knowing.

Ask one question per app and write the answer down: who would raise a ticket the week after this was removed, and what would the ticket say? If nobody can answer, that is a removal candidate and the audit has paid for itself. If the answer is "the warehouse, because the picking list stops", you have just documented a production dependency that existed only in one person's head.

Three dependencies hide particularly well. A Shopify Flow that triggers on an app's event or calls its action. A webhook the app registered against a middleware endpoint someone built. And a human routine — the weekly export, the reconciliation someone does on a Tuesday — which is invisible to every technical check you can run.

Performance is the fourth column people expect here, and it deserves a row rather than a section: Shopify publishes the budget an app had to pass to be listed, so measure against that rather than inventing a threshold. We have written that up separately; the point for the audit is simply to record a figure per app so the ledger has a number in it.

With the ledger complete, each app lands in one of four places. Do this in one sitting — an audit that produces a document rather than decisions was a waste of the afternoon.

Remove. No owner, no dependency, no answer to the ticket question. Most stores find three to six of these, and they are pure margin.

Keep. It does a job, someone owns it, the cost is proportionate. Note the owner's name in the ledger so next year's audit is faster.

Replace. It works but costs too much for what it does, or it is the app pinning you to a legacy integration pattern. Replacement is a project, so give it a date rather than an intention.

Build. The rarest verdict and the one to be most sceptical of. A custom app is right when the thing it does is a business rule you own and nobody sells — your allocation logic, your trade pricing, your particular relationship with a warehouse system. It is wrong as a way to save a subscription fee. You will spend the saving on the build in the first year and then keep paying for maintenance forever, and unlike the vendor you have no other customers to spread it across. If the honest reason for building is that the invoice annoys you, go and negotiate the invoice.

Finish the job properly, because a half-removed app is worse than an installed one: it still carries the data exposure and none of the value.

Uninstall in the admin. Then check the theme for leftover snippets and remove them on a copy first. Then check for Flows and webhooks that referenced it, which will now be failing quietly. Then, if the app held customer data, write to the vendor and ask for confirmation of erasure — Shopify's redact webhook does the asking, but a reply from a human is the only thing you can put in a file. And record the removal date, so that when the November feature turns out to have mattered, the investigation is five minutes rather than a morning.

Then put the ledger in the calendar for a year's time. App estates grow the way they always do — one urgent requirement at a time, each one reasonable — and the only thing that reverses it is a routine somebody owns.

• Custom Shopify apps & back ends
• App performance budgets
• Theme app extensions