Adil AmeeqFull-Stack Developer
Enterprise platform

Pulse

Communication and workforce management in one system

An internal platform that brings messaging, document routing, attendance, leave and task management into a single application, with real-time updates across every module.

Abstract interface mockup showing the Pulse platform: a message thread, an attendance panel and a task list
Representative interface mockup — this system cannot be shown publicly.
Overview

What this system is

Pulse is an enterprise platform that replaces a scattered set of tools — a chat app, an email chain, a spreadsheet for attendance and a separate tracker for tasks — with one system where those things share the same users, permissions and notifications. The modules are separate features, but from the user's point of view it is a single place where work happens.

Category
Enterprise platform
Technologies
Next.jsNode.jsSocket.IOMongoDBRedisReal-time
Client
Client details withheld
The challenge

What was actually wrong

  • Staff communication, formal document routing, attendance, leave and task tracking each lived in a different tool, so the same information had to be re-entered in several places.
  • Nothing was live. People discovered assignments and approvals late because every tool relied on someone remembering to check it or send an email.
  • Permissions differed per tool, which made it unclear who could see what — a real problem for anything involving leave, attendance or formal correspondence.
  • Any replacement had to work for people on the move, on ordinary mobile connections, without a heavyweight app.
The solution

How it was solved

  • A single application with a shared identity, role and permission layer, so access rules are defined once and enforced consistently across every module.
  • A real-time layer built on Socket.IO carrying messages, presence, notifications and status changes, so the interface reflects the current state without the user refreshing.
  • Redis used for presence, socket session state and hot lookups, keeping frequent reads off the primary database.
  • A modular frontend where each area — chat, Daak (document routing), attendance, leave, tasks, user management — is a self-contained feature sharing the same design system and data-fetching conventions.
  • Notification handling routed through one service, so a new message, an approval request and a task assignment all follow the same delivery path instead of three ad-hoc implementations.
Architecture

How the system is put together

The parts, and why each one is there.

  1. 01Next.js frontend with a shared component library and a typed API client.
  2. 02Node.js API server exposing REST endpoints for all module data.
  3. 03A Socket.IO gateway handling authenticated real-time connections, rooms per conversation and per organisational unit.
  4. 04MongoDB as the primary datastore, with schemas shaped around the read patterns each module actually uses.
  5. 05Redis for presence, socket state, caching and short-lived counters.
  6. 06Token-based authentication with role and permission checks enforced server-side on both REST and socket events.
Key features

What it does

The functionality that carries the system, described from the user's point of view.

  • Chat

    One-to-one and group messaging with delivery and read states, media attachments, and history that stays consistent across devices.

  • Daak

    Structured routing of formal documents and correspondence between users and departments, with a traceable trail of who received and actioned what.

  • Attendance

    Daily attendance capture with the records and summaries the operational team needs, rather than a raw log nobody reads.

  • Leave

    Leave requests with an approval flow that notifies the right approver immediately and records the decision against the request.

  • Tasks

    Assignment, status and ownership, with changes propagating live so assignees are not waiting on an email.

  • Notifications

    A single notification pipeline shared by every module, delivered in real time and persisted so nothing is missed while offline.

  • User management

    Roles, permissions and organisational structure managed centrally and enforced across every module and socket event.

Technology

Stack

  • Frontend

    • React
    • Next.js
    • TypeScript

  • Backend

    • Node.js
    • REST APIs
    • Socket.IO

  • Data

    • MongoDB
    • Redis

  • Platform

    • Token authentication
    • Role-based permissions
    • Media storage
Engineering

Development highlights

  • Permissions enforced on socket events as well as HTTP endpoints — a real-time channel is an access-control surface, not just a transport.

  • Presence and connection state kept in Redis rather than in process memory, so the socket layer can run more than one instance.

  • Message delivery states designed around unreliable mobile connections: reconnection, replay of missed events, and no silent message loss.

  • Each module owns its own data access but shares identity, notifications and design system, which keeps features independent without fragmenting the product.

Outcome

Where it ended up

Described in terms of what the system now does. No invented metrics.

  • Communication, document routing, attendance, leave and task tracking now run in one system on one set of permissions.

  • Updates that previously depended on someone sending an email are delivered as they happen.

  • New modules can be added against the existing identity, permission and notification layers instead of being rebuilt each time.

Contact

Building something like this?

Tell me where your situation is similar and where it differs. The differences are usually where the real work is.

Start a conversationadilameeq@gmail.com

Typical first reply within one business day · Lahore, PKT (UTC+5)