When your Shopify Plus app stack is the thing slowing you down
Most $30M Plus merchants I've reviewed are running between 25 and 40 active apps. Some are running more. The merchant usually doesn't know the exact count. Their team has been adding apps incrementally for three to five years, each one solving a specific problem at the time it was installed. The problems often went away. The apps didn't.
That accumulating layer of installed-but-unmanaged software is the single most common drag on Plus merchants in the Adopting-to-Expanding range. Site speed degrades. Conflicts surface in unpredictable ways. Subscription costs creep into the high four figures monthly. And the operational risk of touching anything in the theme grows quietly until even routine work feels dangerous.
This isn't an apps problem. It's a discipline problem. The fix isn't picking better apps; it's building the operational practice of managing what you have.
Why the stack gets ugly
A Plus merchant in the $10-50M range typically grew through the same pattern. Year one or two, a small team installed apps as needed: reviews, lifecycle email, a popup tool, a search upgrade, maybe a subscription engine. Each install solved something specific. The team grew. New people inherited the stack without context for why each app was there. New problems got new apps because nobody had time to evaluate whether existing apps could solve them.
By year three or four, the merchant has 30+ apps, vendor relationships nobody is actively managing, and theme code injected by apps long since uninstalled. The team can't answer simple questions: which app is doing X right now, what would happen if we removed Y, what are we paying for Z and is anyone using it.
If your operations team can't tell you in 15 minutes which apps are actively delivering value and which are sitting dormant, you have an app stack problem. That's the diagnostic.
What good actually looks like at $30M
A well-managed Shopify Plus app stack at this scale has three observable characteristics.
The total app count is actively constrained. Not minimal — Plus merchants legitimately need real functionality from real apps. But the count reflects deliberate decisions, not accumulated history. Most Plus merchants in this range can run effectively on 15-20 well-chosen apps. If you're at 30+, the burden of proof is on each app to justify its slot, not on the team to justify removing it.
There's clear ownership. Someone on the team owns the app stack as an operational responsibility. They know what's installed, what each app does, what it costs, what its alternatives are, and which apps the team is dependent on for daily operations. When a new app gets installed, this person evaluated it and approved it. When an existing app needs review, this person flags it.
Reviews happen on a cadence. Quarterly is the right rhythm. Once a quarter, the owner looks at the full stack and asks three questions per app: Is this still doing the job we installed it for? Is there a better alternative now? Could this functionality be consolidated into another app we're already paying for? The review takes a few hours and produces a short list of changes — usually two to four apps to evaluate, replace, or remove.
The merchant who runs this practice has a fundamentally different relationship with their tech stack than the one who doesn't. One is operating; the other is being operated by their accumulated decisions.
The two failure patterns
There are two ways merchants get this wrong, and they look opposite but produce the same outcome.
Pattern one: tolerance. The team accepts that the app stack is messy and moves on. There's always something more urgent. The stack grows quietly. By the time someone notices the problem — usually because site speed has degraded enough to affect conversion, or because an app conflict broke something during a launch — the cleanup is a multi-month project.
Pattern two: rage cleanup. The team finally pays attention to the app stack, gets overwhelmed, and starts uninstalling apps without proper diligence. Theme code injected by old apps stays behind. Apps that were quietly handling important functionality (sometimes invisibly) get removed without realizing what they were doing. New problems surface in production. The team panics, reinstalls, makes the stack worse.
Both patterns produce the same end state: a worse stack than they started with. The right approach is between them — disciplined, deliberate, ongoing.
What discipline actually looks like in practice
The difference between well-managed and unmanaged isn't more sophisticated tools. It's a small set of practices applied consistently.
The owner maintains a simple inventory document. Not in their head — written down, accessible to the team. Each app has a row. Each row captures: what the app does, who on the team uses it, what it costs monthly, what it depends on, what depends on it, and when it was last reviewed. This document is the source of truth. It gets updated when apps are added or changed.
When new apps are evaluated, they go through a real evaluation process before installation. Not "the marketing team wants this app, install it." A short review: what existing app could do this work, what's the actual cost (subscription plus implementation time plus ongoing support), what's the removal path if it doesn't work. Most apps don't pass this review. The ones that do are deliberate additions, not accumulation.
Removal is treated with the same rigor as installation. Before removing an app, the team confirms what theme code it injected and what manual cleanup is needed. They back up the theme. They communicate the removal to anyone who might be affected. They monitor for issues for a week after removal. This sounds bureaucratic. It's not — it's the cost of operating cleanly. Skipping this is what produces rage-cleanup disasters.
App reviews tag every application with one of four states: keep (working as expected, still needed), watch (working but redundant or expensive, evaluate alternatives), replace (better option exists, plan migration), and remove (not delivering value, plan removal). This taxonomy turns the quarterly review into a manageable exercise. Most apps stay in keep. The watch and replace lists are where the real work happens.
The first 90 days
For a Plus merchant whose dominant gap is Technology, or whose app stack has been left unmanaged long enough that they suspect it's hurting them, here's what to do in the next quarter.
Weeks 1-2: Build the inventory. List every active app. Capture the basics for each: what it does, monthly cost, who uses it, who owns the relationship. Don't try to evaluate yet — just inventory. This usually surfaces 5-10 apps the team forgot existed. Total time: 4-6 hours of focused work.
Weeks 3-4: Run the first audit. Tag each app with keep/watch/replace/remove. Be honest. The first audit usually surfaces 5-8 apps that should be on the watch or replace list. Don't act yet — you're building the picture.
Weeks 5-8: Execute the obvious removals. Apps clearly in the remove tag — uninstall properly, with theme cleanup. Apps in the replace tag where the alternative is obvious — plan and execute the migration. Don't try to fix everything; address the highest-impact items.
Weeks 9-12: Establish the cadence. Schedule the next quarterly review on the calendar. Identify the owner. Document the inventory in a place the team can find it. The goal is not perfection — it's establishing the practice.
A Plus merchant who runs this for two consecutive quarters typically removes 5-10 apps from their stack, reduces their monthly app spend by 15-30%, and observes measurable improvements in site speed. More importantly, they've built the practice that prevents the problem from returning.
Where this fits in your broader maturity
Tech stack discipline isn't a Technology dimension problem in isolation. It connects to Conversion (site speed and stability directly affect CVR), Operations (app costs and conflicts affect operational efficiency), and even Brand (broken pages and slow loads affect brand perception). A merchant whose dominant gap is Technology often has secondary gaps that get better when the stack gets better.
The Tech Stack Discipline Assessment will give a structured read on where your stack management practice sits — your inventory practices, your review cadence, your evaluation rigor when adding new apps, your cleanup discipline when removing them. It's on the MSP roadmap and will launch in the coming months.
Until then, the Holistic Assessment is the action-now path. It evaluates your business across all six dimensions in about nine minutes and identifies whether Technology is the dominant gap that should anchor your 90-day plan, or whether it's a secondary issue connected to a different primary focus.