How to show stock by location on a Shopify product page

First: Shopify already does some of this

Shopify has a built-in pickup availability feature. If you turn on local pickup for a location, most modern themes will show a line under the buy button along the lines of "Pickup available at Main Street, usually ready in 24 hours", with a link listing your other pickup locations.

It's free, it's native, and it needs no app. If what you want is to tell customers they can collect an order, stop here and turn on local pickup. Online Store → Settings → or per location under Settings → Locations → Local pickup.

Where it stops short:

• It only covers locations with local pickup enabled. A shop that sells over the counter but doesn't do click-and-collect doesn't appear at all — even though a customer could walk in and buy the thing.
• It reports availability, not quantity. "In stock" and "we have one left" look identical, so it creates no urgency.
• It's framed around collecting an order rather than answering "which of your shops has this". Those are different questions and customers are usually asking the second one.

Why you can't just write it in Liquid

The natural instinct is to edit the theme. It's worth understanding exactly where that runs out, because the limit isn't your skill — it's what the storefront is allowed to know.

Liquid gives you a variant's total inventory across every location:

{{ product.selected_or_first_available_variant.inventory_quantity }}
<!-- 8 -->

Eight, in total, somewhere. Not three at Main Street and five in the warehouse. There is no per-location breakdown on that object, because the storefront is deliberately not given one.

The one exception is store_availabilities, which is what themes use to render the pickup line — and it is scoped to locations with local pickup turned on. So it inherits the same limitation: shops without pickup enabled aren't in the data at all, and what you get is availability rather than counts.

Per-location quantities live behind the Admin API, which needs an authenticated server-side request. A theme can't make one — it has no credentials, and you would not want it to, because anything the theme holds is readable by anyone who views source.

That's the whole reason this needs an app rather than a snippet. Not complexity — authentication. Somewhere off your storefront has to hold a token and answer the question on the page's behalf.

The caching problem underneath it

There's a second reason even a server-rendered answer misbehaves, and it catches people who solve the first one.

Product pages get cached hard, which is why storefronts are fast. Inventory changes every time someone buys something. Bake stock counts into the cached HTML and you will eventually show a shopper "3 left at Main Street" on a page rendered an hour ago, when the real answer is zero. The shopper drives over to find nothing there, which is worse than never having told them.

Anything trustworthy has to fetch stock after the page loads, and refetch when the shopper switches size or colour — because stock is per variant, and a page that keeps showing the Medium numbers while someone reads about the Large is quietly lying.

So your options are

Worth checking before you install any of them:

• Does it update per variant? Switching from Medium to Large has to change the numbers. If it doesn't, it's showing the wrong stock most of the time.
• What does it do with your warehouses? Your 3PL is a location too, and no customer can visit it. More on that here.
• What can it write? A display feature needs read access only. An app asking for write access to inventory is asking for permission to break your stock levels.
• Does it use theme app extensions? Apps that edit theme files directly leave code behind when uninstalled. Extensions remove themselves cleanly.