How it works
Three things happen in a drop, and only one of them is trusted. Knowing which is which explains most of the app's behaviour.
The chain
1. Intercept — runs in the shopper's browser A shopper hits a page the drop covers and is sent to the waiting room.
2. Queue — runs in the shopper's browser They wait, and are released in batches you control. On release they're given a pass.
3. Checkout — enforced by Shopify A Shopify Function checks the pass against the customer's own record before the order goes through.
Steps 1 and 2 are JavaScript on a page the shopper controls. A determined buyer can skip them. Step 3 is the one that holds, which is why the per-customer limit is enforced there rather than in the page.
This is also why "sold out in eight seconds" and "sold to eight hundred customers" are different outcomes, and why an app that only does steps 1 and 2 can't tell them apart.
Triggers and products are different things
The most common misunderstanding, so it gets its own section.
- Products decide what can't be bought without a pass. Enforced at checkout.
- Triggers decide where a shopper is sent to the queue. Enforced in the browser.
They're set separately, and they don't have to match.
A store-wide trigger queues visitors anywhere on your storefront — but still only gates this drop's products at checkout. So someone buying an unrelated t-shirt during your drop is queued, and then checks out normally. They are never blocked from paying for something the drop doesn't cover.
What a store-wide trigger never touches
Cart, checkout, account and policy pages. Sending someone who is already mid-purchase back to a waiting room strands them, and queueing your refund policy would fail App Store review.
Trigger types
| Type | Fires on |
|---|---|
| Anywhere on the store | Every page except those above |
| A specific page or path | That path and everything under it — /pages/drop also covers /pages/drop/faq |
| A collection page | That collection's page |
| A product page | That product's page |
A drop can have several. Triggers on a scheduled drop only start firing once the waiting room opens — a drop scheduled for next month does not redirect your storefront today.
Queue order
FIFO — join order. First to arrive, first served.
Random — a raffle. Everyone who enters has the same chance, and position numbers aren't shown because they'd be meaningless.
Priority — returning customers get a head start, calculated from their order count and lifetime spend. It saturates, so a big spender can't lap the queue, and guests get nothing because there's no history to price.
The waiting room that opens early
If you set one, everyone who arrives before the doors open is ordered at random at the start time. Not by arrival time — that would just move the race to whenever the room opened.
Anyone in the room before it opens sorts ahead of everyone who joins afterwards. Turning up early beats turning up late; refreshing does nothing.
Passes and limits
When a shopper is released they get a signed pass. It's checked at checkout against the record on their own customer account, so a forged one doesn't match.
The per-customer limit counts across orders, not per basket. Buying one, coming back and buying another is refused at the till rather than reconciled afterwards.
Passes expire. If someone is released and doesn't check out within the validity window, their place is given up.
What shoppers are told about stock
On a drop: Stock shown to customers.
| Setting | Shopper sees |
|---|---|
| Exact number | "412 left" |
| Percentage only | "38% left" |
| Don't show stock | Nothing |
Percentage exists because a count is competitive intelligence. The waiting room is a public page — rivals, resellers and journalists open it too — and "412 left" tells all of them how big your run was. A percentage carries the same urgency without publishing the size of the drop.
The count never reaches the browser when you pick percentage or hidden. It isn't hidden with styling; it isn't in the page source, the network responses, or the live updates.
On a multi-product drop
Each product shows its own figure on its own card, in whichever format you picked. On a five-colourway drop the total answers a question nobody asked — a shopper wants the one they came for, and "412 left" while their colourway is gone is worse than saying nothing. A product with none left shows Sold out, and the cards update live while someone waits rather than freezing at whatever they said when the page loaded.
Percentage of what
Of the most stock the drop has ever had. If you restock mid-drop the baseline rises with it, so the figure can't read over 100%.
Showing how fast it's selling
Optional, off by default: Show how fast the drop is selling adds a line like Selling ~14/min, so someone at position 900 can judge whether stock will reach them.
Once someone is in the queue it adds the projection that goes with it — likely gone in ~10 min — measured against their own estimated wait. Someone two minutes from the front isn't told anything; someone who won't make it is.
It's off by default because it's the one figure that can talk a shopper out of waiting. Turned on, it's honest in both directions — which is the point, but it should be your decision rather than a default you find out about later.
It stays silent unless it can say something true: early in a drop, when nothing has sold, or right after a restock, there's no rate to report and no line appears.
What this does not do
- It does not stop determined resellers. It removes the easy wins.
- The redirect can be bypassed by disabling JavaScript or hitting a product URL directly. That shopper still can't check out past the limit.
- Guest limits are weaker. Without an account there's no identity to count against. Requiring login on a drop closes this, at the cost of some conversions — the choice is yours, per drop.