Example: a Timed Drop Mini App for a VIP Telegram Channel

This is the Mini App I reach for when a brand already has a Telegram channel that can fill a room, and then loses the sale in Direct: “is M still there?”, a card number pasted at 00:03, two people promised the same last hoodie. Instagram killed the hype. Telegram can keep it if the storefront is a clock, not a catalog that sits open all week.

I already wrote a shop bot with cart and Nova Poshta. A drop is not that shop with a countdown CSS. The SKU list is tiny. The spike is the product. If you copy the full store, you will spend the week on delivery forms and still double-sell size M at second zero.

1. The user path in this example

The channel is the waitlist. The Mini App is a door that is locked until `starts_at`, then sells until `qty` is zero.

• Days before: the channel posts photos, size chart, price, the timestamp. No “write us.” A button that opens the Mini App in a waiting room: countdown, nothing to buy.
• At `starts_at` the bot posts the same deep link again. The waiting room becomes a three-SKU grid. MainButton = pay. Size is a tap, not a message.
• Checkout holds the unit for 90 seconds while the invoice is open. Paid webhook commits. Abandoned hold returns to stock. Unpaid at close = gone, not “message the manager.”
• After: a one-line bot message in the channel - “M sold out” - and a private confirmation to the buyer with the packing fields you actually need. Not a CRM dump.

2. The clock is the inventory

A drop dies in two ways: selling a unit twice, or opening late while the hype is already in Direct. Both are database problems, not design problems.

• Server time, not the phone clock. `starts_at` lives in Postgres. The Mini App asks `/drop/state` every few seconds near the open. Do not trust `Date.now()` in the webview.
• Hold is a row with `expires_at`, unique on `(sku, size)` while active. Checkout creates the hold in one transaction. The webhook turns hold → order or the expiry job deletes it. This is the same anti-double-sell as tickets in the payment-bot series.
• One drop = one `starts_at`. Do not “soft launch” for friends at 23:50. The VIP feeling is that everyone hits the same second. A quiet preview is a different SKU on a different day.

3. What I would build first (and what I would not)

A first drop is three SKUs, two sizes, one payment rail, a packing DM. It is not a fashion OS.

• Ship: waiting room, server `starts_at`, hold + webhook, sold-out state, bot line in the channel, HMAC on every buy, one address form after paid.
• Pay with the rail this audience already uses. In Ukraine that is often Mono or LiqPay on a hosted page opened from the Mini App. Stars only if the drop is digital. A hoodie is not a digital good.
• Do not ship first: waitlist raffle, bots that auto-buy, a full returns portal, Apple Pay on a surface that cannot host it, “story stickers,” a live queue animation that hides a 4-second API. If the hold is wrong, the animation is a lie.

4. Who this example is for - and who should just run the shop bot

A drop Mini App is a weapon for scarcity. A shop Mini App is a weapon for assortment. Pick one job per launch.

• Use the drop: merch, a print run, a course cohort with 30 seats, a tasting with 12 tickets. The channel can actually gather people at a time.
• Use the shop article instead: cosmetics restock every week, 40 SKUs, Nova Poshta as a habit. A clock on that catalog is theatre.

A drop is a timestamp with a hold

I would ship this for a brand that already posts to a channel and currently pastes a card in Direct when the comments explode. Next.js waiting room, Postgres SKUs with `starts_at` and `qty`, a 90-second hold, Mono / LiqPay / Stripe webhook, a bot that only announces open and sold out. If that is your Friday night - write via the form. We will scope one drop that can take a real payment at second zero this month, not a shop with a countdown sticker.