Zephiblast - Whatsapp Marketing Tool

ZephiBlast — WhatsApp Marketing SaaS Platform

ZephiBlast is a full-stack WhatsApp marketing automation platform that lets businesses connect their WhatsApp accounts, build contact lists, and run bulk messaging campaigns at scale. I built it as a production SaaS with multi-tenancy, plan-based limits, and a reseller system

The Problem

Most small businesses rely on manual WhatsApp messaging to reach customers copying numbers, sending one by one, no scheduling, no analytics. Official WhatsApp Business API is expensive and requires Meta approval. There was a clear gap for an affordable, self-hosted alternative that gives businesses real campaign tooling without the enterprise price tag.

What I Built

WhatsApp Session Management

Users connect their WhatsApp accounts by scanning a QR code. The backend manages persistent Baileys sessions per user, with heartbeat monitoring to detect disconnections and auto-recovery. Session state is persisted to disk so connections survive server restarts.

Campaign Engine

A full campaign builder where users upload contact lists, compose messages with media attachments (images, video, audio, documents), schedule sends, and track delivery. Campaigns run through a BullMQ queue with configurable delays between messages to avoid WhatsApp rate limiting and bans.

Plan & Quota System

Firebase-backed plan management with Free, Basic, and Pro tiers. Each plan enforces limits on active sessions, daily message volume, and campaign count. Limits are checked at the Redis layer in real time before each message is dispatched.

Reseller System

A white-label reseller module that lets admins create sub-accounts with custom branding, independent plan limits, and API key isolation. Resellers manage their own users without access to the main admin panel.

Real-time Dashboard

Socket.IO-powered live updates for campaign progress, session status, and message delivery. The frontend uses Pinia stores to keep UI state in sync with backend events without polling.

Technical Highlights

• Built on Baileys — an open-source WhatsApp Web reverse-engineered library — to handle WA protocol without the official API

• BullMQ + Redis for durable job queues with per-campaign concurrency control and retry logic

• Randomised message delays (MESSAGE_DELAY_MIN_MS / MESSAGE_DELAY_MAX_MS) to mimic human sending patterns and reduce ban risk

• Firebase Firestore as the primary database — chosen for real-time listeners, zero schema migrations, and tight integration with Firebase Auth

• Multi-stage Docker builds for both services — builder stage compiles assets, runner stage ships only the output

• Nuxt 3 with server-side server/api/ routes handling Firebase Admin SDK calls, keeping private credentials off the client

• Clean Architecture on the frontend — domain entities, use cases, and repository interfaces fully separated from Vue components

• Socket.IO authentication via Firebase ID tokens — every WebSocket connection is verified before joining a user room

Key Decisions

I chose Baileys over the official WhatsApp Business API deliberately. The official API requires Meta approval, a verified business, and costs per message. For the target market — small businesses and resellers in emerging markets — that barrier is too high. Baileys connects as a WhatsApp Web client, which means no approval process and no per-message fees. The tradeoff is that sessions can disconnect and the protocol can change, so I invested heavily in session resilience: heartbeat checks, auto-reconnect, and persistent auth state storage.

Firebase Firestore was chosen over a traditional SQL database because the data model maps naturally to documents (campaigns, users, sessions are all self-contained), and Firestore's real-time listeners made the live dashboard straightforward to implement without building a separate event system. It also meant I could use Firebase Auth for identity without running a separate auth service, keeping the infrastructure lean.

For the frontend I applied Clean Architecture — separating domain logic, use cases, and infrastructure adapters from the Vue layer. This was a deliberate over-engineering choice for a SaaS product: it means the Firebase SDK can be swapped out for a different auth provider without touching a single component, and business rules like plan validation live in pure TypeScript classes that are easy to test in isolation. On a solo project it adds upfront cost, but it paid off when I refactored the auth flow mid-development without breaking the UI.