A commerce platform built around Cash on Delivery and phone-as-identity, and operated from a chat app.
LIVE · PUBLIC STOREFRONT
TOPLABEL.BDCOD-first
Order and email lifecycle
Chat-operated
Order desk runs from Telegram
8
Custom schema migrations
THE STOREFRONT, LIVE ON TOPLABEL.BD
THE PROBLEM
A menswear brand needed a storefront for a market where most orders are paid in cash at the door and most customers have a phone number but not an email address. Commerce platforms are built on the opposite assumptions — payment settles before dispatch, and email is the customer's identity.
Taken literally, that mismatch breaks the order lifecycle in a way that is easy to miss until it is live. The confirmation email fires when payment settles, which under Cash on Delivery is days later or never. Customers who gave only a phone number get emailed anyway, at an address that does not exist, damaging sender reputation with every attempt.
The second constraint was operational: the shop is run by people on their phones, not sitting at an admin dashboard.
WHAT WE BUILT
SHAPE OF IT
A commerce backend and a server-rendered storefront, both prerendered and edge-cached, with images served from object storage through a CDN. Only two API paths are exposed publicly, both third-party webhooks; everything else is reachable only from the storefront process. Requests that arrive without passing through the CDN are refused at the origin.
DECISIONS THAT MATTERED
Order state changes post to a Telegram group with Approve, Ship and Deliver buttons that drive real state transitions and trigger the customer emails. The staff already live in that app. Note the constraint it imposed: the chat API allows only one consumer of updates, so exactly one background process polls while the web process only posts — get that wrong and messages are silently consumed by the wrong worker.
The stock confirmation email fires on payment settlement, which under Cash on Delivery arrives days after the customer wants reassurance, if at all. Replaced with emails on the three states a COD shopper actually cares about — received, shipped, delivered — each gated on the customer having supplied a deliverable address, so phone-only customers are never emailed into the void.
Lookup takes an order code and a phone number and returns a status-only projection — never name, address or email. It answers identically for 'no such order' and 'wrong phone number', so it cannot be used to enumerate valid codes. Phone numbers are normalised so the same number in any local format compares equal. This was deliberately built as a separate query rather than by widening the existing one, which would have leaked the entire order to anyone holding just the code.
Charts resolve by the name of the option group rather than per product, because the platform namespaces group codes per product so two identical scales never share one. The result is that a non-technical operator adding a product inherits the right measurements automatically, instead of the chart quietly being wrong or absent.
Rebranding is done entirely through published extension points — no modifications inside the dependency tree. Rewrites match on file content rather than filename, because build output is content-hashed and filenames change on every release. A build-time check asserts the branding actually landed. The alternative, patching vendor files directly, works until the next dependency install silently reverts it.
The shop is run by people on their phones, not sitting at an admin dashboard. So the order desk lives in the app they already use.
WHERE IT LANDED