Deploying Hustlr on WhatsApp: Why Webhooks Fail on Slow Networks

Most marketplace startups in Africa begin by building a native app. I went a different direction - the marketplace lives entirely inside WhatsApp.

This is the technical story behind Hustlr: a WhatsApp-native AI marketplace built for how Zimbabweans actually buy and sell things. The stack is FastAPI + Baileys + Redis + Supabase + AWS Bedrock, and almost every decision was shaped by one constraint - the user never leaves their chat window.

Why WhatsApp, not a native app?

The numbers make this obvious if you’re building for Zimbabwe:

• WhatsApp is on almost every smartphone in the country. Play Store adoption for new apps is low.
• Data is expensive. People buy small bundles. WhatsApp is often zero-rated or bundled free by networks.
• Trust is already established. People already buy and sell in WhatsApp groups - they just do it manually and chaotically.
• No download friction. No app store listing, no “update required”, no storage complaints on 16GB phones.

The question wasn’t “should we use WhatsApp?” - it was “can we build a real marketplace experience inside a chat interface without it feeling broken?”

The architecture

User (WhatsApp) → Baileys Bridge → FastAPI Backend → AWS Bedrock (Claude)
                                        ↓
                                  Redis (sessions/cache)
                                        ↓
                                  Supabase (data/auth)

Baileys handles the WhatsApp Web protocol - it’s an unofficial library that connects to WhatsApp’s multi-device system. This is the most fragile piece of the stack (more on that below).

FastAPI is the core - it processes incoming messages, manages conversation state, routes to AI when needed, handles listing creation, search, and matching.

Redis handles session state and caching. WhatsApp conversations are stateful but WhatsApp itself doesn’t tell you “this user is mid-flow” - you have to track that yourself. Redis TTLs handle session expiry so stale conversations don’t pile up.

Supabase stores listings, user profiles, transaction records, and handles auth. PostgreSQL underneath, so full-text search on listings works natively.

AWS Bedrock powers the AI layer - natural language understanding for listing creation (“I want to sell my iPhone 12, 256GB, good condition, $350” becomes structured listing data), search intent parsing, and buyer-seller matching suggestions.

How a conversation actually flows

A seller messages the bot:

1. Baileys receives the WhatsApp message, forwards to FastAPI
2. FastAPI checks Redis for existing session state
3. If new conversation → ask what they want to do (buy/sell/browse)
4. If selling → Bedrock parses their natural language description into structured fields (category, condition, price, location)
5. FastAPI confirms the parsed listing back to the user (“Got it - iPhone 12, 256GB, good condition, $350, Harare. Post this?”)
6. On confirmation → Supabase stores the listing, Redis caches it for fast search
7. Buyer searches → Bedrock understands intent (“cheap phones in Harare under $200”) → Supabase full-text search + filters → results sent as WhatsApp messages with images

The AI isn’t a chatbot - it’s an extraction and intent layer. Users talk naturally, the system structures their input. No forms, no dropdowns, no “please select from the following options.”

The hardest problem: Baileys reconnection

Baileys connects to WhatsApp’s multi-device protocol via WebSocket. The connection drops. A lot. Network instability, WhatsApp server rotations, idle timeouts - the bridge goes down multiple times per day.

The naive fix is “reconnect on disconnect.” But the naive fix creates a loop:

1. Connection drops
2. Reconnect attempt fires
3. WhatsApp’s rate limiting kicks in (too many reconnects too fast)
4. Connection gets temporarily banned
5. Longer timeout before retry
6. During that timeout, messages queue up
7. When connection restores, message flood hits the backend
8. Backend processes stale messages (some are minutes old, context is wrong)
9. Users get confused responses to things they said 5 minutes ago

The fix was a multi-layer approach:

• Exponential backoff with jitter - reconnection attempts space out with randomness so multiple bridge instances don’t thundering-herd WhatsApp’s servers
• Message deduplication window - Redis tracks message IDs with a 5-minute TTL, so replayed messages after reconnect get dropped
• Staleness check - messages older than 90 seconds get a different handling path (acknowledge receipt but don’t process the AI intent, since context has likely shifted)
• Health heartbeat - a background task pings the connection every 30 seconds; if 3 consecutive pings fail, it kills the socket cleanly before attempting reconnect (prevents half-open connections that look alive but aren’t delivering)

This isn’t glamorous work, but it’s the difference between a demo and a product. Most WhatsApp bot tutorials skip this entirely because they test on stable WiFi with one user.

Why Bedrock over direct API calls

Three reasons:

1. No cold starts - Bedrock provisions capacity, so response times are predictable. When a user is in a chat flow, 8-second latency kills the experience.
2. Model switching - started with Claude Haiku for fast extraction, can switch to Sonnet for complex matching without changing infrastructure.
3. Regional availability - AWS has African edge presence. Direct API calls from a Harare server to US-West add 300ms+ round-trip that Bedrock’s routing can partially offset.

The tradeoff: cost. Bedrock’s per-token pricing is higher than direct API access. But for a marketplace where each AI call is a short extraction (not a long conversation), the per-message cost stays under $0.001 - acceptable for the reliability gain.

What I’d do differently

Session state architecture. I started with pure Redis for conversation state. Should have used Redis for hot state (current conversation step) but Supabase for conversation history from the beginning. Migrating mid-project meant writing a dual-read layer that checks both stores.

Image handling. WhatsApp compresses images aggressively. I should have built the image pipeline (receive → store original → generate thumbnails → serve) before the listing flow, not after. Retrofitting it meant changing message handling for an already-deployed bot.

Testing the bridge. Unit testing Baileys interactions is painful - the library doesn’t have clean interfaces for mocking. I ended up building a fake WhatsApp message generator that simulates the wire format. Should have done that in week one, not week six.

The broader point

WhatsApp is infrastructure in Africa the same way SMS was infrastructure in the feature phone era. Building on it is messy - unofficial libraries, fragile connections, platform risk from Meta. But the alternative is asking users to download another app, create another account, and learn another interface.

For Zimbabwe specifically, the choice is between a polished native app that 200 people download and a WhatsApp bot that 20,000 people can use without installing anything. The math is straightforward.

If you’re building for African markets and considering WhatsApp as a platform, the technical challenges are real but solvable. The user acquisition advantage is not something you can engineer your way to with a better onboarding flow in a native app.

I build AI-powered systems for businesses in Zimbabwe and across Africa. If you’re exploring WhatsApp automation or AI marketplace ideas, let’s talk.