Skip to content
AM
All projects
SaaS / Messaging

WhatsX Business Platform

A WhatsApp Business outreach dashboard with contact management, validated CSV import with duplicate detection, {{variable}} message templates and a multi-step bulk-send composer, plus prototype scheduling and analytics views.

  • Next.js
  • React
  • TypeScript
  • Node.js
  • MongoDB
  • Material UI

Architecture

Overview

WhatsX is a dashboard for running WhatsApp Business outreach: managing contacts and message templates, composing bulk sends, and watching a scheduled-message queue, with separate admin and user roles. It is a Next.js 14 App Router app. The browser side is one client-rendered Material UI dashboard that switches between eight views. The server side is three Next.js API routes that read and write MongoDB collections for contacts, templates and users. It is a working prototype. Contacts, templates and users are stored in MongoDB. Login, the WhatsApp send step, the scheduling queue and the analytics figures still run on client-side simulations and sample data.

System

text
Browser: React 18 + Material UI (client components)
  AuthProvider (session + role in localStorage)
    -> Dashboard view switcher
       Overview | Contacts | Templates | Compose | Scheduled
       Analytics | Users (admin) | Settings
            |  axios GET / POST
            v
Next.js API routes
  /api/contact_list   /api/template_list   /api/user_list
            |
            v
utils/* per-collection helpers -> MongoClient singleton
            |
            v
MongoDB "whatsX": contactList, templateList, userList

Key design decisions

Thin routes over a data-helper layer. Each route handler only parses the body and shapes the JSON response. The MongoDB reads and inserts live in small helpers under utils/, one pair per collection, so storage code can change without touching the routes. The helpers strip Mongo's _id before returning documents, so the client only deals with its own string ids.

One shared database connection. A singleton class creates the MongoClient once and gives every helper the same connection promise, so concurrent requests don't each open a new connection.

Validate imports before they reach the list. CSV files are parsed in the browser. Name and phone columns are found by header, each row is validated, and rows are split into accepted contacts, duplicates and errors. A duplicate is a phone number that already exists or appears twice in the same file, and each error keeps its row number. The user sees exactly what was skipped and why, and doesn't have to clean the file by hand first.

Templates are plain text with {{variable}} placeholders. A regex pulls the variable names out of the template body. The compose wizard uses them to ask for values and render a live preview. The same extraction runs when templates are imported from JSON, so imported templates come in with their variables already detected.

Role-aware views in a single page. Navigation items marked admin-only are filtered by role, and the view switcher falls back to the overview if a non-admin reaches user management. Analytics shows a regular user only their own logs and campaigns, while an admin sees everything.

Stack

  • Frontend: Next.js 14 (App Router), React 18, TypeScript, Material UI
  • Backend: Next.js API route handlers on Node.js, Axios on the client
  • Data: MongoDB via the official Node.js driver
  • Auth: client-side context provider with admin/user roles (mocked)

Key Implementation Highlights

  1. Built Next.js API routes for contacts, templates and users, backed by per-collection MongoDB helpers and a shared client singleton.

    Backend
  2. Implemented browser-side CSV contact import that validates each row and separates duplicates, both existing and in-file, from row-numbered errors.

    Data
  3. Built a three-step compose wizard with template variable prompts, a live preview and WhatsApp bold, italic and strikethrough formatting.

    Frontend
  4. Added a bulk-send progress dialog that tracks sent and failed counts and records a delivery status for every recipient.

    Frontend
  5. Extracted {{variable}} placeholders from templates with a regex and added JSON template export and import with field defaults.

    Data
  6. Built contact management with search across names, phones and tags, status filters, bulk status changes and CSV export.

    Frontend
  7. Prototyped a scheduled-message queue with priorities, pause and resume, bulk actions, and retries that reschedule failed sends five minutes later.

    Architecture
  8. Restricted user management to admins and scoped analytics logs and campaigns to the signed-in user unless they were an admin.

    Admin

Interested in the technical details?

Let's Talk