WhatsApp has the local merchant base and the broadcast infrastructure (Channels) to support local discovery, but no discovery entry point connecting nearby customers to nearby businesses. Discovery today happens entirely off-platform - word of mouth, signage, or already having the merchant's number saved. Meanwhile quick-commerce apps solve discovery natively and capture the demand a local merchant would otherwise get organically.
Discover is a new entry point into a system that already exists, not a new messaging mechanism. One button, immediately left of Pay, opens a list of nearby opted-in business Channels. You follow the ones you care about; they post catalogue updates; and if you want to buy, you start the conversation. WhatsApp's role is purely as mediator - it owns the discovery surface and the relationship layer, not the transaction.
Self-directed product sense study
Every arrow is user-initiated. There is no cold outreach in either direction.
Tap Discover
New entry point in the Chats header, left of Pay.
Existing surfaceAllow once
Session-based location only - never background tracking.
Consent gateSee nearby channels
Only businesses that opted in, ranked by relevance and recency.
Opt-in both waysFollow
Same mental model as any Channel. The merchant sees a count, never a name.
Identity hiddenGet updates
Catalogue posts and offers arrive in Updates, with mute and block intact.
ReversibleYou message the shop
Identity flows customer → merchant, only when the customer chooses.
GMV momentAn Android shell built to argue the design, not to look pretty. The consent sheet, the hidden-identity rule, and boosted ranking are all playable - those are the three things the case study actually stands on.
Your personal messages are end-to-end encrypted
Next trip kab?
~Saurabh: Kal lonavala ?
AI Product Ecosystem
~Dev Singh: OpenAI Agent going rogue by hacking
Movie?
Photo
Prototype only - an independent concept study, not affiliated with or endorsed by WhatsApp or Meta. Android shell, brand colours approximated.
No third-party tool (WATI, AiSensy, Interakt, any BSP-layer SaaS) can replicate Discover, because none of them own the social graph or the discovery surface - they only reach a merchant's existing contacts through the API. Discover depends on owning the identity layer directly. That's the moat: not a better tool bolted onto WhatsApp, but a capability only the platform itself can ship. And it extends a product that already exists, so there's no new mental model to teach.
The cold-start problem decides this, not the revenue-per-merchant math.
| Model | Mechanism | Verdict |
|---|---|---|
| Placement / subscription fee | Merchant pays upfront to be listed at all. | Rejected. Excludes the underserved small-merchant tail this is meant to serve, and creates a trap: consumer value can't be proven without merchant density, but density would require paying first. |
| Transaction fee | WhatsApp takes a cut of Discover-driven catalogue sales. | Rejected as primary. Requires end-to-end payment tracking via WhatsApp Pay, live in only a handful of markets - too geographically constrained to be the core model. |
| Free-to-list, paid boost | Every opted-in merchant is discoverable free, ranked by relevance and recency; paying lifts ranking or widens radius. | Selected. No barrier to the network effect, no dependency on payment rails, and merchants only pay after seeing organic results - a far easier sell than paying speculatively. |
DISCOVERY MODEL
Customers only see merchants after opening Discover; merchants never receive follower identities, only aggregate counts.
TO LIST
No listing fee removes the merchant-side barrier to the density a discovery product depends on. Boost is optional and later.
PILOT SCOPE
Launch dense before wide - a thin catalogue across a huge geography is the fastest way to kill the feature.
NORTH STAR
Local commerce value attributable to a Discover-driven follow - not sessions, not time-in-feed.
Research suggests Discover gets used intent-first - "I need a bakery near me right now" - not as habitual browsing. So session frequency is the wrong success signal. Leading indicators before GMV is measurable: merchant opt-in rate inside the pilot radius · share of Discover sessions ending in a follow or visit (conversion of intent, not raw sessions) · follow-to-conversation rate · boost adoption among merchants with organic traction.
| Risk | Mitigation |
|---|---|
| Privacy and regulatory exposure. Location-based discovery and merchant-to-consumer connections attract the same scrutiny as other data-driven platform features. | Opt-in and session-based - no passive or background location. Merchants receive aggregate counts and engagement analytics only. This is data minimisation in the design, not a policy promise. |
| Cold start. A discovery feature is worthless with a thin catalogue, but merchants won't opt in before demand is proven. | Free-to-list removes the merchant-side barrier entirely; pilot one dense district to reach usable density before widening. |
| Spam drift. Even with opt-in, aggressive posting after a follow erodes trust. | Standard Channel controls - mute, unfollow, block - stay available throughout, and posting frequency and quality can inform ranking, consistent with existing Business API message-quality handling. |
The findings below are illustrative. They simulate likely feedback based on market patterns and comparable-product research - they are not a record of interviews actually conducted. Before this case study is treated as validated, they need replacing with real conversations. Even 3-4 genuine merchant and customer interviews would substantially strengthen it. Simulated method: 6 local merchants (grocery, salon, tailor, pharmacy, bakery, stationery) and 10 nearby customers.
Discover repositions WhatsApp from a pure messaging tool into a local commerce mediator by adding a discovery entry point on top of infrastructure that already exists. It solves a problem no third-party BSP tool can solve, because it depends on owning the identity layer directly. Free-to-list with paid boost avoids gating the network effect the feature depends on, while still creating a monetisation path once density and trust are established. The core design constraint - opt-in only, merchant-side identity hidden - is what keeps this from becoming cold-outreach spam. It's treated as non-negotiable throughout the design, not as an afterthought.
