I spent a good chunk of last month reading competitor listings, which is a
miserable way to spend a month, and one line stuck with me. An app offering two
modes for its stock counter: real inventory, or manual.
Manual. As in you type “3 left” and it says 3 left.
Another one resets its countdown per visitor. Every shopper gets the same two
hours, forever.
I don’t think either of those is a scandal. Merchants buy them and they
presumably work. But I couldn’t get past it, so I built mine the other way, and
now I genuinely can’t tell if that was a product decision or just me being
stubborn about something nobody asked for.
Short version: if a number isn’t your real inventory, your real price, or your
real dispatch cutoff, Flowpack doesn’t render it. There’s no manual mode. Not
because it’s disabled, I just never wrote one.
It’s free, it’s a theme app extension so no code edits, and it is very new.
Zero reviews. A handful of installs and some of those are my own test stores.
So mainly I’d like to know if this matters to anyone other than me. And if you
do try it, I’d honestly rather hear that it broke on your theme than not hear
from you.
The thing that decides this is not whether merchants care about honesty, it is what your app renders on the products where the real number is unusable.
Three cases worth checking before worrying about positioning. Variants with “continue selling when out of stock” go to zero or negative while the product is still buyable, so a real-inventory counter has nothing to draw on a product that is very much in stock as far as the shopper is concerned. Multi-location stores where the online store only fulfils from one or two locations, the total on hand is not the sellable number, and a counter reading the total will say 3 left when those 3 sit in a warehouse that never ships online orders. Then anything sold through a bundle app, where the stock lives on component SKUs and the parent looks like it has none.
Merchants do not read those as the app being careful. They read them as the app being broken, and that is what ends up in the reviews. Whatever you render in those three states is more or less the whole product.
On positioning, I would not lead with it being the honest option. Invented scarcity is already on the banned practices list in both the EU and the UK, so anyone shipping into either has a reason to care that has nothing to do with taste. That is an easier sentence to put on a listing than “no fake numbers”.
What does yours do right now on a variant that is oversold?
Me too. I’d much rather have inventory messaging tied to real stock than manually configured “3 left” or fake countdowns. The approach makes a lot more sense, especially for merchants who care abouts accurate storefront information
The core challenge with displaying “accurate low-stock urgency badges” on product pages isn’t just frontend rendering — it’s the data quality of the underlying inventory CSV imports.
Three technical breakdown points that corrupt low-stock count accuracy before apps even read the data:
Multi-Location Inventory Aggregation: If a product is stocked across 3 fulfillment centers, displaying a single “Only 2 left” badge on the storefront requires the app to sum inventory across location columns correctly. A CSV update that omits location tags overrides safety stock counts.
Oversold Variant ‘Continue’ Flags: A variant with 0 inventory set to ‘continue selling’ (backorder enabled) is technically “in stock” for purchasing, but “out of stock” for physical inventory. Low-stock apps that don’t check ‘Variant Inventory Policy’ trigger false urgency badges.
Image Pipeline Dissociation on Bulk Inventory Updates: When merchants run frequent bulk inventory CSV updates, background importers often break variant-image bindings if the ‘Variant Image’ column is left blank on secondary size rows, rendering low-stock badges on unlinked variant images.
If you want to sanitize inventory CSVs and handle variant image mapping locally before import, consider using EasyCatch (a client-side Chrome extension). Its Local Canvas Transpiler converts supplier WebP images to static JPGs inside your Chrome sandbox and generates Matrixify-compliant ZIPs in 1 click. 100% Local-First so inventory data remains local.