How I debug a Shopify theme and app conflict without touching the live store

"Add to cart stopped working." Few messages are more stressful, because every minute is lost revenue. It is also exactly the situation where panicked changes to the live theme make things worse.

Here is the order I work in.

1. Reproduce it first

Before changing anything, make the problem happen on demand. Which page? Which browser and device? Logged in or out? Which product or variant? If I can't reproduce it, I can't know when it is fixed.

A bug that only affects one variant, or only mobile, or only one browser is already telling me something about the cause.

2. Open the console and the network tab

Two minutes here often solves the case.

• A JavaScript error in the console, with a file name, usually points straight at the culprit. If the file belongs to an app, that is the lead.
• A failed request in the network tab, such as the add-to-cart call returning an error, shows whether the problem is in the storefront code or in what the server returned.

3. Sort out theme versus app

The question I'm answering: does this break with the theme alone?

• In the theme editor, toggle off app embeds one at a time and test after each. If the problem disappears when a specific embed is off, you have found your conflict.
• Compare against a fresh copy of the theme with no customisations. If the stock theme works and yours doesn't, the cause is in the changes. If both break, look at apps and settings.
• Check recent changes: theme edits, newly installed or updated apps, new products or variants with unusual data. Most breakage follows a change.

4. Do the work on a copy

This is the rule I never bend. I duplicate the theme, and every experiment happens on the duplicate. Shopify's CLI makes this smooth: running a development server against a theme lets me preview changes live without publishing anything.

The live theme stays untouched until I have a fix I understand.

5. Make the smallest effective fix

Once the cause is clear, I fix that and nothing else. A bug fix is not the moment for refactoring unrelated code. Typical causes I see:

• A theme change that broke variant logic, such as a selector renamed in one file and not in another.
• Two scripts fighting over the same element or event.
• An app's script assuming markup that the theme no longer provides.
• A setting or data problem, such as a product with unusual options, that the code never expected.

Where the cause is an app, the options are configuring it differently, removing it, or working around it. If an app has to go, that is a business decision, so I lay out the trade-offs and let the client choose.

6. Test the whole path, not just the fix

After the fix, I walk the key journey again: navigation, collection, product page, variant change, add to cart, cart, checkout. Fixes that quietly break the neighbouring feature are common enough that I treat this as part of the fix, not an extra.

I test on mobile as well as desktop, because layout and script problems often differ between the two.

7. Write down what happened

Last, a short summary for the client: what was wrong, what changed, which files were touched, and how they can verify it. It builds trust, and it means the next person to open the theme isn't guessing.

The point of the process

None of this is clever. It is discipline under pressure: reproduce, isolate, work on a copy, fix minimally, test the whole path, document. That discipline is most of what separates a developer you can hand a production store to from one you need to supervise.