Project Overview

This project is an internal messaging operations platform built around WhatsApp-based communication. The product serves teams who manage ongoing customer or lead conversations, send structured outbound messages, validate contact lists, and coordinate follow-up work across multiple operators.

In this project, the platform is not limited to campaign blasts. It also supports live chat handling, message history, media attachments, reusable templates, contact assignment, scheduled sending, and import/export flows. That combination turns fragmented manual processes into a single operational system.

The intended users seem to be operations staff, support teams, campaign managers, and admins responsible for both day-to-day messaging activity and account-level configuration.

Quick Summary

Project Type: Internal messaging and campaign operations platform
Platform: Web application
My Role: Developer
Team Size: N/A
Duration: N/A alone

Problem

The core problem was operational fragmentation.

Teams needed to do several related jobs at once:

run outbound messaging campaigns
manage inbound conversations
keep contact records organized
assign contacts to internal users
reuse approved message content
send files and media reliably
verify whether numbers were reachable on WhatsApp

Without a dedicated system, those workflows typically get spread across spreadsheets, messaging devices, manual exports, and ad hoc follow-up habits. That creates obvious issues: poor visibility, inconsistent ownership, duplicated work, missed replies, and very little control over message history.

There was also a technical challenge behind the business workflow. The product had to operate across more than one WhatsApp integration model, while still giving operators one consistent interface.

Goal

Success looked like giving operational teams a single place to manage customer messaging work end to end.

That meant:

one inbox for handling conversations
one workflow for sending text and media
one place to maintain contact ownership and notes
support for both reactive chat and proactive campaigns
enough operational tooling to manage templates, exports, scheduling, and validation tasks without leaving the system

My Contribution

My role on this project was as a developer working close to the operational core of the product.

The work here was not just about adding screens. It involved implementing the application behavior that ties the system together: how messages are created, stored, scheduled, broadcast to the UI, sent through different providers, updated from webhooks, and reflected back into contact state.

I contributed in the areas that make an operations product feel coherent:

the chat workflow and message lifecycle
service-layer handling for different messaging backends
real-time broadcasting for inbox updates
media and file attachment flows
contact assignment, unread state, notes, and draft handling
scheduling and command-based background processing
admin-facing tooling for templates, users, and number-check operations

What I appreciate about this kind of work is that the engineering decisions are tightly connected to how real teams operate. Small implementation choices directly affect how reliable and usable the system feels.

Tech Stack

Frontend

Blade templates
Used for server-rendered application pages and admin screens. This made sense for an internal tool where delivery speed and close coupling to backend workflows were more important than building a separate SPA.
JavaScript with jQuery
Used heavily for dynamic chat behavior, AJAX-driven updates, modal flows, filters, attachment handling, and message interactions. The chat UI is stateful and interaction-heavy, but still implemented inside a Laravel-rendered app.
Laravel Echo + Reverb client setup
Used to push real-time message and contact events into the inbox UI without requiring full page refreshes.
DataTables and Select2
Used for operational tables and selection-heavy admin workflows.

Backend

Laravel 10 / PHP 8.1
Provided the MVC structure, routing, middleware, events, scheduling, storage, and authentication backbone.
Guzzle
Used to communicate with external messaging APIs and download or upload media where required.
Laravel Sanctum
Present in the project for token-based auth support, although the main operator workflow relies on session-based authentication.
Laravel Excel
Used for importing number lists and exporting validation results.

Infrastructure

MySQL
The schema design centers on a relational model for contacts, messages, campaigns, businesses, templates, users, and validation jobs.
Laravel Reverb / Broadcasting
Used for private-channel events so operators can see new contacts and message updates in near real time.
Laravel Scheduler / Artisan commands
Used for recurring operational tasks such as campaign execution, scheduled sending, and number checks.
Local file storage
Media files are stored locally and then either downloaded directly or exposed through signed routes for provider access.

Integrations

WhatsApp Business API path Used for direct provider-style messaging, including media upload and webhook-based status/message ingestion.
UltraMSG path Used as an alternate WhatsApp integration model for sending, deleting, checking numbers, and receiving webhook events.

Testing

PHPUnit Present in the repository, but the actual automated test coverage is minimal. In practice, this project looks more operationally verified through manual workflow testing than through a mature automated suite.

Architecture Notes

The codebase is organized as a fairly standard Laravel application, but the interesting part is the domain evolution visible in the schema and services.

At the center of the model is a business-scoped messaging domain:

bizs separate tenant-like business contexts
users belong to a business and carry role information
contacts belong to a business and track assignment, unread state, notes, draft text, and last-message linkage
messages act as the canonical event log for both inbound and outbound communication
campaigns group outbound sends
template_messages and attached files support reusable operational content
num_checks and num_check_data model batch validation workflows

One architectural choice I liked is the use of a shared ChatServices layer as the application-facing message pipeline. Controllers do not directly implement each provider flow. Instead, they funnel message creation through one service that:

persists the local message record
handles scheduled versus immediate sending
selects the provider path
updates message status and provider IDs
broadcasts the result back to the UI

That is a practical maintainability decision. It keeps the operator workflow consistent even when the transport layer differs.

Another notable decision is the move toward a business-level global broadcast channel. Instead of forcing the client to subscribe to every contact-specific channel, the application also emits business-wide events for new contacts and message updates. That is a useful scalability step for inbox-style products where the contact list can grow significantly.

The system also reflects a real operational reality: asynchronous work matters. Scheduler-driven commands process campaigns, number checks, and scheduled messages every minute. Even though the queue configuration in the example environment is simple, the product design itself clearly assumes background execution.

What I Built

Unified Chat and Messaging Workflow

Purpose
To give operators a single interface for handling live conversations, composing replies, attaching files, using templates, and managing follow-up work.

Engineering challenges
The messaging flow had to support text, images, video, audio, documents, scheduled sends, draft preservation, unread tracking, and provider-specific delivery behavior without making the UI feel fragmented.

Implementation highlights
I can see a central message send pipeline, contact history pagination, draft persistence, chat export, forwarding, assignment flows, and client-side chat state management with AJAX and real-time updates.

Business value
This turns messaging from a one-off action into a manageable workflow. Operators can stay inside one system instead of switching between devices, files, and manual notes.

Dual Integration Messaging Layer

Purpose
To abstract two different WhatsApp integration approaches behind one operator experience.

Engineering challenges
Different providers have different request formats, media rules, identifiers, webhook behavior, and status semantics. The application still needs one consistent data model and one consistent UI.

Implementation highlights
The service layer branches by business configuration and routes sends through either a WABA service or an UltraMSG service. Message records store provider-specific IDs, transport type, media metadata, and delivery state so the rest of the system can stay coherent.

Business value
This reduces coupling between the operator workflow and the external provider choice. That makes the platform more flexible operationally and less brittle architecturally.

Real-Time Inbox Updates

Purpose
To keep the inbox current as messages arrive, new contacts are created, or send status changes.

Engineering challenges
An inbox product feels unreliable very quickly if users have to refresh manually. At the same time, broadcasting can become noisy or expensive if the channel model is naive.

Implementation highlights
The project uses Laravel events, private broadcast channels, Reverb, and Echo. Message events are broadcast both to contact-level channels and to a business-level global channel, which is a smart compromise between fidelity and subscription overhead.

Business value
Real-time visibility matters in an operations environment. It helps teams respond faster, avoid duplicate handling, and trust the system as the source of truth.

Template and Media Workflow

Purpose
To support repeatable outbound communication with reusable content and attached files.

Engineering challenges
Templates are not just text snippets here. They can include multiple files, ordering, and different message types, and those assets still need to flow correctly through the send pipeline.

Implementation highlights
The platform stores template records and related file records separately, allows ordering, and injects template content plus attachments into the standard send flow. Media files are stored locally and passed to providers either as uploaded files or signed URLs, depending on the integration.

Business value
This improves consistency for teams that send recurring messages, while still supporting richer communication than plain text.

Contact Ownership and Operator Workflow

Purpose
To turn a raw message feed into an assignable workload.

Engineering challenges
A shared inbox becomes chaotic without contact ownership, unread state, notes, and visibility into the latest activity.

Implementation highlights
The contact model includes assignee, notes, unread flags, received counters, draft text, and a last_message_id pointer that helps drive ordering and inbox behavior. Admin users can also filter by ownership and manage users through dedicated admin routes.

Business value
This is where the product becomes an operations tool rather than just a messaging shell. It supports accountability and day-to-day coordination.

Number Validation Import/Export Flow

Purpose
To validate batches of phone numbers before or alongside campaign activity.

Engineering challenges
Bulk data workflows are often neglected, but they matter a lot operationally. The system needs to ingest files, process records incrementally, and return usable output.

Implementation highlights
The project models number-check jobs and job rows separately, imports spreadsheets through Laravel Excel, processes pending items on a scheduled command, and exports results back to Excel.

Business value
This reduces wasted effort on invalid or unreachable contacts and supports cleaner outbound operations.

Key Engineering Challenges

Workflow complexity in one product

One challenge was that this product combines several modes of work: live chat, campaigns, media handling, admin management, and batch validation. Those workflows are related, but they do not behave the same way. The architecture had to let them share a domain model without collapsing everything into one overly rigid flow.

Provider abstraction without losing operational clarity

Supporting both WABA and UltraMSG is more than a config toggle. Media upload, inbound webhook payloads, message identifiers, and status updates all differ. The code addresses this by centralizing the application workflow and letting provider-specific services handle transport details.

Real-time state consistency

Inbox-style software is sensitive to stale state. Unread counts, latest message order, drafts, message status icons, and active chat history all need to stay aligned. The project handles this through event broadcasting, UI refresh hooks, and explicit contact state fields such as last_message_id and received_count.

Media lifecycle management

Media is harder than text. Files have to be stored, typed, named, exposed safely, and transmitted differently depending on the provider. The use of local storage plus signed routes is a practical solution for serving files to external messaging services without exposing everything publicly.

Operational background processing

Campaign execution, scheduled sends, and number validation all run on scheduler-driven commands. That introduces timing, retry, and observability concerns. Even in a relatively compact codebase, the operational model is clearly asynchronous.

Authorization and tenant boundaries

The product separates businesses and uses role-based admin access. That matters because inbox data, templates, users, and message traffic should not bleed across organizational boundaries. The business-scoped queries throughout the code reflect that concern, even though some areas could be tightened further.

Outcome

From the codebase, this platform became a fairly complete internal messaging console rather than a narrow campaign sender.

It unified:

outbound campaigns
inbound conversation handling
reusable content management
contact assignment
media messaging
scheduled follow-ups
number validation workflows
basic admin operations

Verification was focused on end-to-end user flows, regression checks, and manual staging validation.

Why This Project Matters

This project matters in my portfolio because it shows the kind of engineering work I enjoy most: turning messy real-world operations into a coherent product.

What makes it valuable to me is the mix of concerns. I had to think about user workflow, backend architecture, external integrations, asynchronous processing, real-time behavior, and data modeling at the same time. It is a good example of application engineering where business understanding matters as much as code structure.

I also like that it is honest complexity. This is not complexity created by scale theater. It comes from trying to make day-to-day operational work dependable.

What I Learned

This project reinforced how important it is to design around workflow, not just entities.

A contact, a message, and a campaign are simple records on paper. In practice, they carry timing, ownership, delivery state, provider behavior, unread logic, and UI expectations. What I found interesting was how quickly a messaging product becomes a state-management problem.

It also taught me the value of a shared application service layer when a product depends on multiple external providers. Keeping one internal workflow while isolating provider-specific logic is not glamorous, but it is one of the decisions that keeps a system maintainable as requirements grow.

Finally, this project is a good reminder that internal tools deserve the same architectural care as customer-facing products. When operations teams rely on a system all day, clarity and reliability are product features.

Systems Engineering Case Study