August 31, 2026 · The Evolution team

When to Fire a Shopify App: A Practical ROI Audit

A Shopify app should stay only when it still does a valuable job better or more safely than the available alternative. “We have always used it” is not evidence. Neither is a dashboard that credits itself with revenue.

The practical test is whether the app creates incremental contribution, saves real labor, or controls a material risk after you count its full cost. If you cannot identify the job, owner, evidence, and safe exit path, the app belongs on an audit list. That does not mean uninstalling it immediately.

Start with the job, not the monthly price

Write one sentence for every paid app:

We pay [amount] so [owner] can produce [outcome], measured by [evidence].

Examples:

• We pay for a back-in-stock app so the retention owner can recover otherwise unavailable demand, measured by delivered alerts, resulting orders, and contribution after message cost.
• We pay for a returns app so support can process eligible returns with fewer manual steps, measured by handling time, errors, and customer wait time.
• We pay for a fraud tool so the operator can reduce preventable losses, measured by reviewed orders, confirmed fraud, false positives, and chargeback cost.

If the sentence ends with “because it helps conversion,” make it more specific. Which stage changes? Compared with what baseline? Does the reported revenue represent a sale the app caused, or any sale it touched?

Shopify's current app-management documentation says an app's About page can show billing and usage charges, permissions, extensions and functions, pixel connections, compatibility issues, and app history. Use that page as evidence, then check vendor invoices and your card statement for charges outside Shopify.

Calculate the fully loaded monthly cost

The subscription is only the visible line. Use:

Fully loaded cost = subscription + usage fees + external charges + operator time + overlapping tools + attributable remediation cost

Operator time matters when someone exports data, fixes sync failures, moderates output, or checks another dashboard each week. Convert recurring time to cost with a consistent hourly value. Do not invent a cost for vague annoyance; count documented work.

Overlap is also common. An email platform, theme, review tool, and popup app might each offer a signup form. The question is not which feature list is longest. It is which implementation owns the job without creating a second source of truth.

Use the Shopify app stack cost audit to find every charge, then the revenue leak worksheet to place recurring software beside the other costs that affect contribution.

Match the evidence to the kind of app

Not every app should be judged by attributed sales.

Revenue apps

For an upsell, messaging, search, or recommendation app, measure the business step it can plausibly change:

• eligible sessions or customers
• exposure to the feature
• progression to the next funnel step
• completed orders
• discounts, returns, and contribution on those orders

Treat an app's attributed revenue as a lead for investigation, not proof of incrementality. A post-purchase tool can touch orders that customers would have placed anyway. A popup can claim a subscriber who was already looking for the signup form.

Where volume permits, run a clean holdout or controlled test. For a low-traffic store, use the methods in the low-traffic A/B testing guide: fix objective defects directly, use a reversible rollout, and do not declare a winner from a few orders.

Labor-saving apps

For a support, fulfillment, feed, or reporting app, record:

• minutes per task before and after
• tasks per month
• exception and error rate
• time spent maintaining the automation
• work that still requires judgment

Then calculate:

Monthly labor value = tasks per month × verified minutes saved ÷ 60 × hourly value

Compare the result with the fully loaded app cost. A hypothetical app that costs $120 and saves four verified hours valued at $35 each creates $140 of gross labor capacity. That $20 gap is thin if the workflow fails often, but it might still be worthwhile if it also prevents expensive errors. Label the assumptions instead of pretending the answer is exact.

Risk and compliance apps

Some tools protect a downside rather than lift revenue. Backup, consent, accessibility, fraud, tax, and security tools need a risk test:

• What failure does the app address?
• How likely and costly is that failure in this store?
• Is the app configured and monitored?
• Is Shopify, the theme, or another approved tool already covering the same control?
• What evidence shows the control works?

Do not remove a risk control merely because it has no attributed sales. Equally, do not keep one because its category sounds important when nobody has verified its configuration.

Seven signs an app is no longer paying for itself

An app becomes a serious removal candidate when several of these are true:

1. Nobody can name its current owner or decision.
2. Its key output has not been reviewed in the last complete business cycle.
3. A native Shopify, theme, or existing-tool feature now performs the same job.
4. The plan grew with contacts, orders, or usage, but the value was never rechecked.
5. The app claims revenue without a credible baseline, holdout, or causal mechanism.
6. It creates recurring manual cleanup, customer confusion, tracking errors, or storefront performance work.
7. The team would not reinstall it today at its current fully loaded cost.

One sign is not an automatic verdict. A seasonal app can be quiet for months. A backup should rarely generate visible activity. Record the operating reason for the exception and the next review date.

Use a keep, change, test, or remove decision

Do not reduce the audit to keep versus fire.

For a test, choose a period that includes the workflow the app is meant to handle. Do not test a back-in-stock tool when nothing restocks or a support tool during an unusually quiet week. Keep promotions, inventory, and major site changes noted so a noisy period does not create false confidence.

Build the uninstall runbook before touching the button

Shopify's current uninstall guidance warns that an app can leave theme code, hold data that might not be recoverable, manage inventory at an app location, or support workflows and storefront features that stop after removal. It also says uninstalling cancels future Shopify-managed recurring charges, but a current-cycle charge can remain and external subscriptions must be canceled separately.

For every removal candidate:

1. List theme blocks, checkout extensions, pixels, functions, webhooks, flows, inventory locations, customer-facing widgets, and data feeds that depend on it.
2. Export the data, configuration, templates, and reports you are allowed and need to retain.
3. Record screenshots and settings required for rollback.
4. Identify the replacement or manual fallback and its owner.
5. Check the vendor's uninstall steps for theme code or external billing.
6. Choose a low-risk removal window and test product pages, cart, checkout, notifications, analytics, and affected operations afterward.
7. Verify both the next Shopify invoice and any external payment method.

Shopify's app-charge documentation explains that generated charges can still appear on an upcoming invoice and that canceling inside a vendor product does not necessarily uninstall the Shopify app. Confirm the actual billing state rather than assuming the button handled everything.

If the app affects storefront performance, compare real-user data before and after using the Shopify site-speed and Core Web Vitals guide. Do not promise a speed lift merely because one script disappeared; measure the page types and devices that matter.

Run the audit quarterly and after major changes

Review the stack after BFCM, a replatforming, a theme change, a major plan increase, or a new native Shopify feature. Otherwise, a quarterly review is frequent enough for most small stores.

The output should be one page: app, job, owner, fully loaded cost, evidence, dependency risk, decision, and review date. Start with the most expensive app whose evidence is weakest, build the exit plan, and make one controlled change. The goal is not the smallest app count. It is a stack where every tool has a defensible job.