The trap is not the apps, it is the stack they form
Shopify's app store is genuinely good: reviews are real, installs are one click, most apps do their one job well. The trap is accretion. Every app injects scripts into the storefront, adds fields to the admin, and rents a slice of your data model. One app is a tool; nine apps are a second store bolted onto the first, and nobody remembers why half of them are installed. The Shopify services page covers the platform boundary; this page is the app-stack audit and the custom-versus-app math.
The four trap patterns
- The script tax. Each storefront app ships JavaScript that loads on pages that do not need it. Ten apps later, mobile LCP is three seconds and every Core Web Vitals fix fights an app you pay for monthly. If an app's widget only matters on product pages but its script runs sitewide, that is the tax being paid.
- The subscription creep. $15–40 per app per month sounds small until the stack hits eleven. Apps bought for a launch that ended, duplicates bought because two apps each did half a job, and "free" plans that paywall the one feature you actually need. The audit question: what did this app sell or save last month?
- The data silo. Apps that keep your data hostage, reviews, bundles, loyalty points, subscriptions stored in the app's system, exportable only as CSV (maybe). Leaving means rebuilding that data elsewhere, which is exactly how the monthly fee becomes permanent.
- The checkout conflict. Shopify's checkout is sacred ground, but apps that touch cart logic, discounts and shipping can fight each other and the theme. Symptoms: discount codes failing silently, shipping rates doubling, mobile-only abandonment at the payment step, the checkout-triage page for the day it fully breaks.
When custom-built is the honest answer
The math, done properly: custom costs more once and nothing monthly; an app costs little monthly and compounds forever. Custom wins when (a) the logic is your differentiation, a bundles model or B2B pricing rule no app models exactly; (b) the subscription × remaining store lifetime exceeds the build; (c) the data must live in your systems (the Airtable/Notion boundary guide covers where data belongs); (d) you are paying three apps to half-deliver one job. Custom loses when an app already does the job well and support matters more than control, which is most of the time, and saying so is the audit's job.
The audit, in the order it should run
- List every app with cost, scripts injected, and last revenue attribution
- Kill the orphans (nothing attributed in 90 days), measure the speed delta
- Merge the duplicates, two apps half-doing one job is a custom-build signal, not a third app
- For survivors, run the custom-vs-app math honestly, including maintenance
- Document what remains and why, so the stack never quietly regrows
The audit is scoped work with a measurable payoff, speed, fees, admin sanity. Bring the app list; the calculator prices any custom work the audit recommends.