In short
There is no number. What matters is how many of them inject code into the storefront, how much that code costs in load and interaction time, and whether each one is still doing a job. A store with twenty apps that mostly run in the admin can be perfectly fast, while a store with six that each add scripts to every page can be slow. Audit by what reaches the browser and by what each app returns, not by the count in the admin.
Count what reaches the storefront, not what is installed
Apps fall into two groups. Some do their work in the admin or through background processes: inventory tools, accounting connectors, order management, fulfilment. These have essentially no effect on how fast the store loads for a customer.
Others add code to the storefront. Reviews widgets, upsell tools, popups, live chat, wishlists, currency selectors, tracking pixels and personalisation scripts all load in the browser, and each one adds requests, JavaScript to parse and work for the device to do.
The second group is where the cost lives, and it is the group to audit. Open a product page, look at what loads, and identify which app each script belongs to. That list is the real answer to how many apps your store has.
And check the pages individually. Many storefront apps load on every page whether they are used there or not, so a chat widget and a review script may be running on your collection pages, your articles and your cart as well as the product page where they are needed.
The costs beyond page speed
Conflicts are the first. Two apps that both modify the cart, both inject a discount, or both alter the same theme section will eventually interfere, and the symptom appears as an intermittent bug that nobody can reproduce.
Theme debt is the second. Older apps ask you to paste code into theme files, and that code often stays behind after the app is removed. A theme carrying three years of leftover snippets is slower and harder to change than the same theme clean.
Cost accumulation is the third, and it is quietly significant. A dozen subscriptions at a modest monthly price each becomes a meaningful annual number, and it is rarely reviewed once approved.
Upgrade friction is the fourth. Every storefront app is a dependency during a theme update or a migration, and a store with many of them takes longer to move or redesign, which shows up as a larger project cost later.
And fragility is the fifth. Each storefront app is a third party whose outage becomes your outage, on a page your customers are trying to buy from.
How to audit what you have
List every installed app with its monthly cost, what it does, who asked for it, and whether it touches the storefront. Most stores find several nobody remembers installing.
For each one, ask what would break if it were removed today. Apps where the answer is nothing obvious are candidates immediately. Apps where the answer is a feature nobody uses are candidates too.
Then ask whether the platform now does it natively. A great deal of functionality that once needed an app is built in, and stores frequently pay for tools that duplicate something already available in the admin, in the theme, or in the checkout.
Remove them properly. Uninstalling an app does not always remove the code it added to your theme, so check the theme files and the checkout customisations after each removal, and confirm the storefront still behaves.
Measure before and after on a real device. If removing four apps did not change the load or interaction measures, they were not the problem, and it is better to know that than to keep guessing.
Decide what earns its place
An app earns its place when it produces revenue or saves time that exceeds its total cost, and total cost includes the page weight it adds and the fragility it introduces.
For revenue apps, that is testable. Turn the feature off for a period or for a share of traffic and compare revenue per session. Several categories of storefront app survive on the assumption that they help rather than on evidence.
For operational apps, the calculation is simpler: hours saved against subscription cost. These are usually easy to justify and they rarely affect the storefront anyway.
Prefer apps built with the platform's modern extension model, which run in a more contained way than pasted scripts, and prefer one app doing three jobs to three apps doing one each, since each additional vendor adds its own load and its own failure mode.
Then review the list on a schedule, twice a year. App sprawl is not a decision anyone makes; it accumulates, and a regular review is the only thing that reverses it.
Auditing by what loads, not by what is installed
- Apps installed
- 19
- Admin or background only
- 11, no storefront cost
- Loading scripts on every page
- 5
- Loading only where used
- 3
- Leftover code from removed apps
- Found in two theme files
- Action taken
- Two removed, three limited to the pages that need them
- Measured after
- Mobile interaction and load times on a real device
An illustrative audit. The useful split is the second and third rows, since the installed count on its own says almost nothing about how the store performs.
Related questions
Do apps directly affect my Google rankings?
Not directly, and they affect the page experience measures that form part of how a page is assessed, and they affect conversion regardless of ranking. A slow, unresponsive product page loses orders whether or not the ranking moves, which is usually the larger cost.
Does uninstalling an app remove its code from my theme?
Not always. Apps using the modern extension model generally clean up after themselves, while older ones that asked you to paste code into theme files often leave it behind. Check the theme and any checkout customisations after removing an app, and test the storefront afterwards.
Is one app doing several jobs better than several specialists?
Usually, for storefront features, because each vendor adds its own scripts and its own potential outage. The exception is where a specialist tool is meaningfully better at something that drives revenue, in which case the extra weight can be worth it if you have measured the benefit.