Product EngineeringProjectL3:healthcare-outreach-dashboard

Healthcare Outreach Dashboard Rebuild

A consumer health company's WhatsApp program dashboard for healthcare professionals, rebuilt from Streamlit to Next.js and FastAPI with dual-control broadcasts, tuned on Azure until no request stalled over 2 s, and now live in production.

60 s → <2 s
Worst stall on a 0.2 s endpoint on Azure, before and after the API and worker split
~45 hours
First commit to the complete replacement dashboard, across 53 pull requests
61 of 61
Report responses identical to the live system after the backend migration

Role: Sole engineer of the dashboard rebuild: architecture, backend migration, Azure environment and performance work, directing parallel AI coding agents. The WhatsApp bot itself was built by colleagues.
Period: Oct 2026
Client: Consumer health company

Results

60 s → <2 s
Worst stall on a 0.2 s endpoint on Azure, before and after the API and worker split
After the follow-up changes, Azure met every performance target except two first calls after a restart, which the next change fixed (verified locally).
~45 hours
First commit to the complete replacement dashboard, across 53 pull requests
Parallel AI coding agents implemented much of the code under written specs; I reviewed, tested on Azure and merged every pull request.
61 of 61
Report responses identical to the live system after the backend migration
Compared against a read-only copy of production data; 6 bot conversation pages also matched.
~2,900 tests
Automated backend tests, plus 173 browser tests with accessibility checks
Up from 31 backend and 12 browser tests at the start of the rebuild.

Problem

The program's admin dashboard was a Streamlit app that queried the production database from the page, sent WhatsApp messages in-process, had no approvals or tests, and read its metrics from a separate function called with a key in the URL. Operators needed to run user management, reports, webinars, bot knowledge and template broadcasts on their own, safely. The rebuild replaced the legacy dashboard and is now live in production.

Contribution

I moved the legacy app aside with its history and ported every feature into typed FastAPI domains behind a Next.js BFF started from the team's AI application template. Each spec mapped the legacy logic it replaced, and legacy bugs were fixed on the way, such as an access token sent in a URL and a retry that could resend messages.
I made broadcasts safe to run: a state machine with approval by two different people, checked in the API and again in the worker, a frozen audience, a resumable runner on Cosmos DB leases, a per-recipient claim ledger, a fail-closed send allowlist and an append-only audit log.
Instead of developing on synthetic data or writing to production, I built a resumable, parity-checked, read-only copy of production data in the new database, and replaced the metrics function with a native endpoint checked by a parity script.
I measured a baseline on Azure first: 60, 19 and 23 s stalls on a 0.2 s endpoint. A loop-lag watchdog traced them to one event loop shared by heavy aggregation and background sweeps, so I split API and worker into separate App Service apps and precomputed summaries with watermarks and a visible freshness indicator.
I kept the dashboard bilingual, Indonesian by default with English, and accessible: axe WCAG 2.2 violations went from 4 to 0, guarded by browser tests.