Cart: 100 × bundle · stock: 1
Clean browser
Reproduced
01 — Reproduce
Reproduce it
See the problem happen for myself, in a clean browser or a real checkout, not from a description.
Problem Clinic · real cases, real fixes
Bring me the problem. I'll find the cause.
Stores and apps break in ways that cost money quietly. Here are real problems clients brought me, how each one was traced to its root, and what was left in place so it never came back.
Client names withheld: problems are private. Details on a call.
- slowest screen, before and after
- 16s → 1.7sslowest screen, before and after
- needless database writes stopped
- 1.47Mneedless database writes stopped
- descriptions restored
- 225descriptions restored
- bundles protected from overselling
- 45bundles protected from overselling
How I work a problem
Symptoms lie. Causes don't.
The fix you'd guess from the symptom is usually wrong. Every case below followed the same four steps, which is why each one stayed fixed.
Response time per screen
Before16.3sAfter1.7sserver: us-east · db: mumbai
02 — Measure
Measure it
Logs, query statistics and response headers before opinions. The number shows where to look.
Suspects
Slow coderuled outBig imagesruled outToo many appsruled outServer far from databaseCause03 — Find
Find the cause
Keep going until the real reason is found, and check the systems next to it that could do the same.
- Fixed on a copy firstTested end to endDaily check switched onStays fixedRevert plan ready
04 — Fix
Fix it and guard it
Fix on a copy first, test end to end, then leave a check behind so it can't quietly come back.
Case files
Solved, case by case.
Case 01Stock and orders don't add up
Bundles were selling stock that didn't exist
Multi-store book retailer · UK, Pakistan, Saudi Arabia
45
bundles protected from overselling
1What they saw
A bundle whose books had one copy left still let a customer put 100 bundles in the cart. The storefront said in stock.
2What I found
45 bundle products across three stores were either not tracked at all, or tracked but set to keep selling at zero. Shopify needs both settings right before it will stop a sale, and only one had ever been set.
3What I changed
Tracking switched on, each bundle's stock set to its scarcest book, and selling at zero turned off, on all 45 products.
So it stays fixed: Tested with a real 100-unit add to cart on every store: Shopify now caps it. A live component sync is the long-term fix, and was scoped as the next step.
- Shopify Admin API
- GraphQL
- Inventory
Case 02Stock and orders don't add up
The sales report didn't match the money
Multi-store book retailer · 4 currencies
89
orders that were silently misreported
1What they saw
Revenue in the reports and what actually came in never quite agreed, in both directions.
2What I found
The reports used the order total saved at checkout. A scan of recent orders found 89 of 1,101 had been edited afterwards, items removed or added, with no refund recorded, so the saved total was simply out of date.
3What I changed
Every report moved to Shopify's live order total, which already includes refunds, partial refunds and edits.
So it stays fixed: Made a standing rule for every report and dashboard built since, on every store.
- Shopify Admin API
- Reporting
Case 03My store or app is slow
An admin app took up to 16 seconds per screen
Subscription brand · UAE
16s → 1.7s
slowest screen, before and after
1What they saw
Every click inside the team's admin app inside Shopify hung for seconds. Nothing in the code looked slow.
2What I found
The server was running in the US while the database sat in Mumbai, so every query crossed the world, several times per page. On top of that, each page asked Shopify for staff details the store's plan can never return, and waited for the error.
3What I changed
Pinned the server next to the database, cached the call that always fails, and loaded the rest in parallel.
So it stays fixed: The response header that shows the server region is now the first thing checked whenever an app feels slow.
- Vercel
- Supabase Postgres
- Prisma
- Shopify App
Case 04My store or app is slow
The homepage was downloading fonts it never used
Book retailer · UK
10 → 2
font files on first load
1What they saw
The homepage felt heavy on mobile before anything useful appeared.
2What I found
The theme loaded ten weights of one display font when the design used two, preloaded Shopify fonts the store had replaced, and held the whole page until the font file arrived.
3What I changed
Cut the font to the two weights in use, removed the wasted preloads and let the font stylesheet load without blocking the page.
So it stays fixed: Each change written up with a one-step revert, applied to the live theme only after checking on a copy.
- Liquid
- Core Web Vitals
Case 05Checkout and discounts misbehave
Customers lost their discount by clicking too fast
Book retailer · Pakistan
0
lost discounts in repeat checkout tests
1What they saw
Shoppers ticked “Pay online & save 5%”, pressed Buy Now straight away, and reached checkout without the discount.
2What I found
Reproduced it in a clean browser: the page left for checkout before the cart had saved the choice. An earlier test had passed only because an old cart still remembered the setting from a previous run.
3What I changed
Checkout now waits for the choice to be saved, then continues with the exact button the shopper pressed.
So it stays fixed: Re-tested with a brand-new browser profile and a real checkout: discount applied and cash on delivery hidden, every time.
- Shopify Functions
- Cart API
- JavaScript
Case 06Checkout and discounts misbehave
A promised saving that checkout refused to give
Book retailer · UK
100%
of active discounts audited for conflicts
1What they saw
The cart told shoppers “complete the set and save”. At checkout, the saving never appeared.
2What I found
The new discount logic was right. An older welcome code that was still active was set not to combine with product discounts, and Shopify quietly picked the code over the promise.
3What I changed
Lined up the combination rules across every active discount so the two work together.
So it stays fixed: Before any “you'll save” message goes live, every active code and automatic discount is now checked for conflicts.
- Shopify Discounts
- GraphQL
Case 07I'm worried about data, security or costs
A database that anyone with the public key could read
Retail group · several stores and internal tools
401
what every old key returns today
1What they saw
A routine review found a test-era “allow all” database rule still live, and a code repository that had been left public.
2What I found
Between the two, store access tokens and order data could be reached from outside. The same pattern was then searched for across every project, not just the one where it was spotted.
3What I changed
Closed every open rule, made the repositories private, rotated every store token and app secret, and made webhooks reject anything unsigned.
So it stays fixed: A daily automated security check now scans every project and lands a report on the owner's desktop.
- Supabase RLS
- Shopify
- Webhook HMAC
Case 08I'm worried about data, security or costs
A dashboard that kept knocking its database offline
Multi-store retailer · inventory dashboard
1.47M
needless database writes stopped
1What they saw
The dashboard went down when the database hit its monthly data limit. After the reset, usage climbed from 40% to 76% within hours.
2What I found
The database's own query statistics, not the app code, gave it away: a background sync had made 751,126 inserts and 718,726 updates by re-checking every collection on every run, changed or not.
3What I changed
Sync now touches only what changed, skips writes when nothing is different, and heavy totals are calculated inside the database.
So it stays fixed: Every number checked against the old method on all 5,226 products before switching over.
- Supabase
- Postgres
- Edge Functions
Case 09I'm worried about data, security or costs
Bots on a WordPress site's login and forms
Non-profit content site · WordPress
Back online
the call-me form, protected
1What they saw
The login page and a “call me” form were attracting automated traffic, and the form had been taken down.
2What I found
Bots were reaching the server directly, and the login page and form had nothing to tell a script from a person.
3What I changed
Put Cloudflare in front, limited login attempts, and brought the form back with a human check real visitors barely notice.
So it stays fixed: Daily backups to a private repository with secrets stripped out automatically.
- WordPress
- PHP
- Cloudflare
- Turnstile
Case 10A bulk update hurt my products or SEO
One import broke 225 product descriptions
Book retailer · UK
225
descriptions restored
1What they saw
After a bulk update, product pages showed “�” where £ signs, Arabic text and accented letters used to be.
2What I found
One step of the import read the file in the wrong encoding. Every special character was replaced, and the original was lost, so it could not simply be undone.
3What I changed
Rebuilt each description by language and character, then re-imported with UTF-8 enforced from start to finish.
So it stays fixed: Every bulk update now ends with a store-wide scan that must find zero broken characters before it counts as done.
- Shopify Admin API
- UTF-8
- SEO
Your problem isn't here yet?
Most of these started as one line from a client. Send yours and I'll tell you where I'd look first.
Bring your problem
Describe what's going wrong.
Tell me what you're seeing, in your own words. I'll look at it and reply with what I think the real cause is and how I'd fix it. Free, and no obligation.
What you get back
- A first diagnosis: the likely root cause
- How I'd fix it, and how to stop it coming back
- A clear quote, only if you want me to do it