A Shopify store does not end up with 43 apps because someone made one reckless decision.
It happens one reasonable install at a time.
You add reviews, then bundles, then filters, then email capture, then subscriptions, then reporting, then automation. Each app solves a real problem when it goes in.
Then six months later, nobody can clearly tell you which app owns what.
That is the point where app count stops being trivia and starts becoming a diagnosis problem.
If you are trying to fix flat growth, do not start by chasing a prettier app count. Start by working out which jobs are duplicated, which tools still earn their place, and which workarounds Shopify can already replace.
That is the real audit.
Too many Shopify apps is a symptom, not the diagnosis
An app count can tell you where to investigate, but it cannot tell you whether the store is healthy.
A store with 30 well-managed apps may be easier to operate than a store with eight poorly integrated ones. The real problem begins when the stack contains duplicated functions, abandoned workarounds, and tools that no longer match how the business actually runs.
App count matters less than duplicated jobs and competing tools
Start by asking what each app does, not how many apps you have.
Several apps may look different in Shopify admin while doing overlapping jobs. For example:
- A review platform may also collect user-generated content.
- An email platform may also run forms and popups.
- An upsell app may also create bundles.
- A subscription platform may also manage loyalty benefits.
- A search app may also control filters and product recommendations.
- A page builder may also add product-page widgets.
Overlap is not automatically bad. It becomes a problem when two tools are both trying to control the same customer experience, data, or theme element.
You may find that one popup is managed in your email platform while another is controlled by a standalone form app. Your theme may display related products while a recommendation app injects a second section underneath it. Shopify may already be applying a promotion while a discount app is trying to reproduce the same logic.
The important question is not, "How many apps do we have?"
It is, "How many systems are trying to perform the same job?"
The hidden cost of legacy apps and disconnected data
The subscription fee is only one part of an app's cost.
An app may also create:
- extra work for staff
- duplicate customer records
- conflicting tags or metafields
- inconsistent reporting
- more support tickets
- more theme dependencies
- additional testing whenever the store changes
- greater risk when an integration fails
Legacy apps are particularly awkward because their original purpose may no longer be obvious. The person who installed the app may have left the business, the promotion it supported may have ended, or Shopify may now provide the same basic function.
Disconnected data creates another problem. When subscriptions, loyalty, email, reviews, and customer service all hold separate versions of the customer record, it becomes harder to look at the data underneath it and see what is really happening.
A tool can be useful on its own while still making the wider system harder to manage.
Signs your app stack has become harder to manage
Your app stack deserves attention when:
- staff do not know which app controls a storefront element
- similar customer emails are being sent by different platforms
- removing or editing a theme section feels unusually risky
- apps create conflicting discounts, tags, or customer properties
- monthly app charges are difficult to explain
- nobody reviews whether installed tools are still being used
- reporting differs depending on which app you open
- the store relies on manual exports to move data between tools
- support teams regularly blame another app for an issue
- a basic change requires several developers or app providers
These are signs of unclear ownership and architecture. Removing apps may help, but the underlying fix is to decide which system should own each job.
Do Shopify apps actually slow your store?
Some do. Some do not.
An installed app may affect the storefront, Shopify admin, checkout, customer accounts, fulfilment workflows, or several areas at once. Treating every app as an equal performance problem leads to bad decisions.
How storefront scripts can affect page performance
Customer-facing apps may load JavaScript, stylesheets, images, fonts, or requests to external services. This is common with tools for:
- reviews
- personalisation
- search
- recommendations
- popups
- chat
- loyalty
- wishlists
- social feeds
- analytics
- upsells and cross-sells
The impact depends on how the app is built, where it loads, and whether the customer is using the feature.
An app that loads a small product-page block only when needed is different from a tool that loads a large script across every page. Two apps doing similar work may also have very different performance effects.
Do not assume that a familiar or expensive app is efficient. Do not assume that a small app is slow either. Measure the actual behaviour.
Why some apps create operational drag without slowing pages
An app can create problems even when it has little or no storefront impact.
Admin-only and operational apps may complicate:
- order routing
- inventory updates
- customer tagging
- returns
- fraud checks
- reporting
- product feeds
- email triggers
- accounting
- fulfilment
The result is operational drag rather than a visibly slower page.
For example, an app may create tags that trigger a second automation, which changes an order property, which then affects a fulfilment rule. The workflow may function, but only one person understands it.
That is still app bloat.
A healthy app stack should make the business easier to run. When the stack creates hidden dependencies, additional training, and repeated manual fixes, the store is paying for complexity even if page speed is unaffected.
Measure the impact before blaming every installed app
Create a baseline before removing anything.
Test the same pages under the same conditions:
- homepage
- a collection page
- a high-traffic product page
- cart
- any landing page used for paid traffic
Record what loads, which apps appear on the page, and whether any obvious errors occur.
Then disable or remove one candidate at a time and repeat the tests. Changing several apps at once makes it difficult to know which change caused the result.
Performance is only one outcome. Check whether removing the app affects:
- add-to-cart behaviour
- product options
- discounts
- analytics events
- customer messages
- subscription selections
- reviews
- search and filters
- tracking pixels
- checkout extensions
The point of measurement is not to prove that apps are bad. It is to identify which tools create enough value to justify their cost and complexity.
Audit every app by the job it performs
Do not begin an app audit by opening Shopify admin and uninstalling everything unfamiliar.
Build a complete view of the stack first.
Record the function, owner, cost, and data access
Create one row for every installed app and record:
- app name
- primary job
- internal owner
- monthly or usage-based cost
- pages or processes affected
- customer data accessed
- Shopify data changed
- other apps connected
- theme blocks, embeds, or code used
- last review date
- what would stop working if it disappeared
The internal owner should be a person or role, not a department.
Someone needs to know why the app exists, how success is measured, and what to do when it fails. Apps without an owner tend to stay installed long after their value has disappeared.
Also note where important data lives. Before replacing a reviews, loyalty, subscriptions, or customer-service app, you need to know whether its data can be exported and whether the replacement can use it.
Group apps by customer journey stage to expose overlap
Once the list is complete, group apps by the job they perform.
A practical structure is:
Traffic and acquisition
Advertising feeds, landing pages, SEO, affiliate tools, and tracking.
Product discovery
Search, filters, recommendations, quizzes, and collection merchandising.
Product decision
Reviews, product options, sizing, comparison tools, and product media.
Cart and checkout
Upsells, bundles, discounts, gifts, shipping, and payment tools.
Retention
Email, SMS, subscriptions, loyalty, referrals, and customer accounts.
Operations
Inventory, fulfilment, returns, fraud, customer service, and accounting.
Measurement
Analytics, attribution, reporting, and testing.
This usually reveals overlap quickly.
You may discover that your search app, theme, and recommendation platform all control product discovery. Your email platform, loyalty app, and subscription tool may each send post-purchase messages. Your analytics platform may duplicate reports that nobody reads in Shopify.
Grouping by job turns a long app list into a system you can evaluate.
Mark each app as essential, replaceable, redundant, or unknown
Give every app one of four labels.
Essential
The app performs a necessary job, supports meaningful revenue or operations, and does not have a suitable replacement.
Replaceable
The job is necessary, but Shopify or another existing tool may be able to do it well enough.
Redundant
The app duplicates another system, supports an expired use case, or is no longer being used.
Unknown
Nobody can confidently explain what it does, who owns it, or what would happen if it were removed.
"Unknown" does not mean uninstall it immediately. It means investigate.
Check the app settings, theme customisations, automation history, billing records, and staff knowledge. An unfamiliar app may be inactive, or it may quietly support an important process.
The audit is not complete until every app has a clear classification and next action.
Check Shopify's native tools before keeping a workaround
Shopify has continued to add built-in features and first-party apps. A third-party tool that was necessary a few years ago may no longer be the simplest way to do the job.
Native does not automatically mean better. It does mean you should check what Shopify can already do before adding another platform to the stack.
Product discovery, filters, and recommendations
Shopify Search & Discovery can cover many common product-discovery requirements, including collection and search filters, search-result controls, and product recommendations.
It may replace a separate app when you mainly need:
- standard collection filters
- filters based on product data or metafields
- basic search merchandising
- related products
- complementary product recommendations
Your theme still needs to support the relevant sections and filtering experience.
A specialist search app may remain justified when the store needs more advanced capabilities, such as complex merchandising rules, deeper personalisation, unusual catalogue structures, or integrations with external product data.
The decision should be based on the buying experience you need, not the length of the feature list.
Bundles, discounts, and promotional offers
Shopify Bundles can create fixed bundles and multipacks from Shopify admin. Shopify also supports common discount structures such as percentage discounts, fixed amounts, free shipping, and buy-one-get-one style promotions.
This may be enough for straightforward offers such as:
- a fixed product kit
- a multipack
- a basic buy-more promotion
- a collection-wide discount
- a free-shipping offer
- a simple buy X, get Y promotion
A specialist app may still be needed for:
- customer-built bundles
- complex mix-and-match offers
- advanced gift logic
- subscription bundles
- dynamic cart upsells
- post-purchase offers
- detailed bundle analytics
- promotions with several interacting conditions
Do not keep a complex promotion app because you might use its advanced features one day. Keep it when the current offer genuinely requires them.
Before changing your offer structure, review how it fits into your wider Shopify conversion optimisation process. A simpler technical setup will not help if the offer itself is still unclear.
Forms, email capture, and customer communication
Shopify Forms can handle popup and inline forms, collect customer information, apply tags, and support segmentation.
That can replace a standalone form app when the requirement is relatively simple:
- newsletter signup
- early-access registration
- wholesale enquiries
- lead capture
- customer preference collection
- a basic welcome offer
Shopify's own marketing tools can also support common email campaigns and automations.
A specialist email or customer-data platform may still be the right choice when you need:
- complex lifecycle flows
- advanced behavioural segmentation
- email and SMS orchestration
- detailed revenue attribution
- extensive template controls
- multiple brands or regions
- deep integration with loyalty, subscriptions, or support systems
The mistake is not using a specialist platform. The mistake is paying for a separate popup app, form app, and email tool when one platform already handles the full job.
Automation, reporting, and customer account features
Shopify Flow can automate tasks using triggers, conditions, and actions. Shopify also provides customer segments that update as customers meet the relevant criteria.
These tools may replace smaller automation apps used for tasks such as:
- applying customer or order tags
- sending internal notifications
- routing orders
- flagging products or inventory
- triggering follow-up workflows
- grouping customers by behaviour
- connecting supported Shopify apps
Shopify's customer account system can also cover common account functions such as viewing orders, managing profile details, and maintaining saved addresses. Additional account features depend on the store's configuration and requirements.
Built-in reports may cover straightforward operational and sales questions, although reporting depth still depends on the Shopify plan.
A specialist platform still makes sense when you need advanced cohort analysis, consolidated multi-channel reporting, custom data models, or a customer portal with complex functionality.
Before paying for another system, write down the exact question or workflow it must solve. "Better reporting" and "more automation" are not specific enough.
Keep specialist apps where the business case is clear
Replacing every third-party app with a Shopify feature is not the goal.
Established stores often have requirements that go well beyond the default platform. A strong specialist app can be far more reliable and cost-effective than building or maintaining the same capability internally.
The standard should be clear value, not native purity.
Complex subscriptions, loyalty, and personalisation
Subscriptions affect payments, orders, customer accounts, inventory, forecasting, and retention. Loyalty programmes affect customer identity, rewards, discounts, and communication.
These systems can become deeply embedded in the business.
Keep a specialist app when it supports requirements such as:
- flexible subscription changes
- product swaps
- prepaid plans
- failed-payment recovery
- custom loyalty tiers
- points and reward logic
- referral programmes
- personalised customer experiences
- detailed programme reporting
The same applies to personalisation. If product recommendations or onsite content use meaningful customer or behavioural data, replacing the system with a basic related-products block may reduce performance rather than improve it.
The app should still have a measurable role. "We have always used it" is not a business case.
Advanced search, international selling, and operational workflows
Large catalogues can require search logic that goes beyond standard filters. International stores may need complex market, tax, currency, fulfilment, or translation workflows.
Operational apps may also be essential when they connect Shopify to:
- warehouses
- suppliers
- accounting systems
- enterprise resource planning software
- shipping providers
- returns systems
- customer-service platforms
- wholesale processes
These apps should not be removed because they are expensive or difficult to understand.
Instead, document the dependency and test whether the app is still the best way to meet it. A specialist operational tool can save far more than its subscription cost when it prevents errors and manual work.
Features that need specialist data, integrations, or control
A third-party app earns its place when the required data, integration, or level of control does not exist elsewhere.
Ask:
- Does it hold data the business actively uses?
- Does it connect systems that would otherwise be isolated?
- Does it support a customer experience that contributes to sales or retention?
- Does it remove meaningful manual work?
- Does it provide controls the team uses regularly?
- Could the business operate safely if it stopped working?
If the answers are clear, keep the app and manage it properly.
The purpose of an audit is not to eliminate tools. It is to make intentional decisions about them.
Decide which apps to remove first
Do not begin with the most complicated or revenue-critical app.
Start with the easiest decisions. Early removals reduce noise and give the team confidence in the process.
Start with duplicate tools and features nobody owns
The first candidates are usually:
- Apps tied to expired campaigns
- Tools that are installed but inactive
- Duplicate apps doing the same job
- Features already available in the theme
- Features already covered by another paid platform
- Apps that no team member uses or owns
A countdown timer left over from an old sale is a better first candidate than the subscription platform processing recurring orders.
Look for duplicate storefront elements as well. Two review widgets, two recommendation sections, or multiple popups are visible signs that ownership has become unclear.
Choose which system should own the experience, migrate what is needed, and remove the others.
Prioritise apps that add cost or manual work without clear value
A cheap app can be expensive when it creates weekly manual work.
Consider the full cost:
- subscription and usage charges
- staff time
- developer time
- support effort
- data reconciliation
- training
- errors
- delayed store changes
- performance impact
An app that saves several hours of reliable work may be worthwhile. An app that costs little but creates repeated errors may not be.
Use the audit to compare cost with the actual job being done. Do not rely on an app's feature list or the reason it was originally installed.
Avoid removing revenue-critical tools just to reduce the app count
Treat these areas with particular care:
- subscriptions
- product reviews
- search
- product options
- bundles
- loyalty
- email and SMS
- checkout customisations
- tracking
- fulfilment
- returns
- accounting integrations
Removing one of these systems without a migration plan can affect active customers, open orders, reporting, and revenue.
A lower app count is not worth breaking a working customer journey.
Replace critical tools only when you have confirmed the new system covers the required use case, data has been migrated, and the full experience has been tested.
Uninstall apps without breaking the store
Clicking "Uninstall" is the final step, not the first.
A safe removal process should account for the storefront, theme, data, integrations, automation, and customer communication connected to the app.
Map every affected page, script, integration, and automation
Before removing an app, record:
- where it appears on the storefront
- which theme blocks or app embeds it uses
- whether code was manually added to the theme
- which products, variants, or collections it changes
- which metafields, tags, or metaobjects it creates
- which apps or external systems receive its data
- which emails or notifications it sends
- which workflows depend on its events
- what historical data needs to be retained
Export important data where possible.
Take screenshots of settings and customer-facing elements. Record any custom code, design choices, or rules you may need to recreate.
For a critical app, prepare a rollback plan before making changes.
Test the theme, checkout, tracking, and customer messages
Make changes in a duplicate theme where possible, then test the full journey.
Check:
- homepage
- navigation
- search
- collection filters
- product pages
- product options
- add to cart
- cart drawer or cart page
- discounts
- checkout
- order confirmation
- customer accounts
- subscription management
- transactional emails
- marketing emails
- analytics events
- mobile and desktop behaviour
Place a test order when the app affects purchasing, payments, discounts, or fulfilment.
Do not rely on the homepage looking correct. App problems often appear only on specific product templates, customer accounts, carts, or post-purchase steps.
Remove leftover code and compare the store afterwards
Modern Shopify apps often use theme app extensions, but older apps and custom installations may have added code directly to the theme.
After uninstalling, check for:
- unused theme snippets
- old script references
- empty app blocks
- redundant CSS
- broken Liquid references
- abandoned metafields
- duplicate tracking
- console errors
- missing content or spacing
Do not delete unfamiliar code until you have confirmed where it came from. Use theme version history, app documentation, or developer support to identify it.
Once cleanup is complete, repeat the same tests you ran before removal.
Compare:
- page behaviour
- performance
- conversion tracking
- customer messages
- staff workflows
- error reports
- support enquiries
One controlled removal with clear results is more useful than a mass uninstall that creates uncertainty.
Keep the app stack lean as the store grows
App bloat is rarely solved permanently by one cleanup.
Without an installation policy and regular review, the stack will gradually expand again.
Require a clear problem, owner, and success measure before installation
Before installing a new app, answer:
- What specific problem are we solving?
- Can Shopify or an existing app already solve it?
- Who will own the tool?
- Where will it affect the customer journey?
- What data will it access or change?
- How will we know whether it is working?
- What is the ongoing cost?
- How could we remove it later?
Avoid installing apps just to see what they do on the live store.
Use a development store or duplicate theme when practical. Set a review date at the time of installation so trial apps do not quietly become permanent infrastructure.
Most importantly, define success before the app is installed. Otherwise the team has no objective reason to keep or remove it later.
Review app overlap, cost, and performance each quarter
A quarterly app review does not need to become a giant project.
Review:
- new apps installed since the last audit
- apps with increasing charges
- tools without active owners
- duplicate features
- expired campaigns
- changes to Shopify's native capabilities
- customer-facing performance
- failed or paused integrations
- data exports and access permissions
- upcoming theme or platform changes
Ask each app owner to confirm whether the tool is active, useful, and configured properly.
That is how you stop a 43-app cleanup from becoming a 60-app cleanup six months later.
Use a store-wide audit to decide whether apps are even the first fix
Apps are only one part of the system.
A messy stack may be contributing to weak conversion, but the main bottleneck could still be the offer, product page, traffic quality, checkout experience, or retention journey.
If the store has 43 apps and you still cannot tell which part is actually broken, run the Store X-ray. It gives you a store-wide view of where the customer experience may be leaking, so you can decide whether app cleanup is the first fix or simply one part of it.
If you already have a strong hunch and want the likely layer confirmed first, take the Revenue Bottleneck Quiz.
The goal is not fewer apps for the sake of it.
It is a Shopify store where every tool has a clear purpose, every major workflow has an owner, and the customer experience is not being held together by layers of forgotten workarounds.
When the app stack is clear, the store becomes easier to improve. Theme changes carry less risk. Staff know where to make updates. Data is easier to trust. New tools get added deliberately rather than reactively.