Back to selected work

CASE STUDY / INTERNAL OPERATIONS PRODUCT

Social Media
Operations.

A team needs to know who owns each comment, whether a reply reached its destination, and what happened next. I brought handling, history, and reporting into one workspace.

PRODUCTSocial media operations
MY ROLESole developer · Full-stack
STATUS In active company use
MAINTENANCEEntire product lifecycle
Read the delivery decisions

01 / ENGINEERING DECISIONS

Ownership, delivery states, and provider boundaries.

The reply arrived.
The confirmation didn’t.

A timeout can leave an operator unsure whether a reply was delivered. The next action depends on what the system can confirm.

01

Make ownership explicit.

Two operators can act on the same incoming record. I made claiming transactional and tied handling permissions to the claim owner, with checks in the backend as well as the interface. Dashboard and Telegram replies share a delivery reservation so concurrent requests cannot both start a send.

Workflow integrity
02

Keep uncertainty visible.

I separate confirmed delivery, definite failure, and uncertain outcomes. Provider confirmation is required to mark a reply as sent. Recovery can take longer than an immediate retry, so the interface keeps that state visible while the previous attempt is checked.

Delivery reliability
03

Preserve source context.

Social comments, Maps reviews, and Play reviews expose different capabilities and histories. I kept their workflows and reporting separate. Written reviews and ratings-only records use distinct handling rules, and missing provider data is shown as unavailable rather than being reported as zero.

Data integrity

Validation includes service tests for concurrent Dashboard and Telegram requests, missing delivery confirmation, claim matching, and ownership restrictions.

REPLY DELIVERY / ILLUSTRATED FLOW

  1. 01ClaimCheck the operator’s ownership.
  2. 02ReservePrevent overlapping sends across channels.
  3. 03SendSubmit the operator’s written reply.
Confirmed

Record the provider’s reply confirmation and handling history.

Definite failure

Keep the draft available for a safe retry.

Uncertain

Keep the draft, block resend, and check the previous attempt.

A timeout alone does not confirm delivery or make a resend safe.

02 / PRODUCT EVIDENCE

Follow the record.

Response History records reply status and dates. Attribution remains unavailable when no operator evidence was retained.

Product screenshots · Private identities hiddenRecorded replies with dates, status, and attribution fields.

Reporting and review examples use September 2026. Customer identities and private text are hidden; the product data is unchanged.

03 / IMPLEMENTATION

What I built.

My work covered the operator interface, APIs, database, provider connections, reporting, and deployment. Each layer supports the same handling workflow.

Interface & operator workflows
I designed the screens and implemented inbox handling, review workspaces, role-based access, and reporting views.
Backend, database & integrations
I built the APIs, persistence, provider connections, claim ownership, reply delivery, and recorded history.
Realtime updates & reporting
I implemented workspace updates, period comparisons, operational records, and PDF exports.
Deployment & maintenance
I deploy releases, investigate issues, maintain data integrity, and update integrations as provider requirements change.

IMPLEMENTATION / THE STACK I USED

The product’s
technical layers.

Frontend · React, Vite, Tailwind CSS
React Router for workspaces and Recharts for reporting views.
Backend · Node.js, Express, PostgreSQL
JWT authentication, ownership rules, and separate persistence for comments and review domains.
Realtime & reporting · Socket.IO, jsPDF, PDFKit
Inbox updates and PDF exports for workspace and Telegram reporting.
Deployment · Docker, Nginx, GitHub Actions
Frontend requests use the same-origin API path through Nginx to the backend service.

04 / IN PRACTICE

From daily handling
to a monthly review.

Operators and management can track assignments, replies, and reporting in one place.

A visible owner for each handling action
Claim assignment and role checks show who is responsible and govern who can classify or reply.
Response history that can be followed
Saved attempts, delivery outcomes, and audit records let the team review what happened. Attribution uses recorded evidence, including when the operator is not known.
Management reporting in the same workspace
A manager selects a month, compares it with previous periods, reviews daily trends, and exports the overview and comparison in one PDF.
Integration issues that can be investigated
Health states and sync information help distinguish a connection issue, partial data, and an action awaiting confirmation.

CONTINUE EXPLORING

Return to
the project overview.

Back to the portfolio Email Azkha

Product preview

Product screenshot · Private identities hidden