BD Doctors Directory
Lead Software Engineer / System Architect
A doctor discovery and digital-profile platform for patients, built across four services: a Next.js public site with programmatic SEO pages per city and specialty, a doctor-facing patient/prescription web app, a Vue 3 admin and growth-CRM console, and a Node.js/MongoDB API — with a purpose-built pipeline for acquiring and onboarding doctors onto the platform.
Problem
A doctor directory is only as good as the doctors actually listed on it, and getting a doctor from 'never heard of us' to 'fully listed with a published video profile' takes a cold call, a WhatsApp conversation to collect their data, an in-person video shoot, and a sales follow-up — a process that naturally ends up spread across a spreadsheet, a phone, and someone's memory of who to call back today. That acquisition pipeline needed to live inside the product itself, while the public-facing side needed real programmatic SEO — city × specialty landing pages, individual doctor and hospital pages — for patients to actually find those doctors once listed.
Approach
Four services share one MongoDB/Express API, evolved from the same backend architecture as DocBee — booking, Socket.IO, Agora, Firebase, AWS S3 — reusing proven building blocks rather than rebuilding them. A Next.js public site generates dedicated sitemaps for doctors, hospitals, cities, specialties, and city-specialty combinations so the directory is actually crawlable at scale. A React web app gives doctors their own patient and prescription workspace. A Vue 3 admin console — also packaged as a desktop app via Electron — runs both day-to-day operations and the doctor-acquisition CRM. OpenAI assists with structured extraction from uploaded prescriptions and documents instead of requiring manual entry.
A hard problem I solved
The doctor-acquisition funnel is modeled as a single document per lead: one record moves in strict order through new, no_answer, follow_up, whatsapp_group, listed, video_scheduled, video_review, video_published, a revenue stage, and finally advocacy — so the call team's notes, the WhatsApp data collection, the video shoot schedule, and the sales cadence all write to the same record instead of splitting across systems. Terminal states — rejected, invalid — are deliberately excluded from that ordered stage list, since nothing is 'further along' than an exit from the funnel. The follow-up cadence itself isn't hardcoded: how many hours after a missed call to try again, and on which channel, lives in a separate playbook document per stage that the marketing team can edit without a deploy, expressing either a specific sequence of follow-up offsets or a steady repeat interval. Modeling the acquisition process as data instead of code is what let it keep changing as the team learned what actually worked, without every adjustment needing an engineer.
Status
Live at bddoctorsdirectory.com. The oldest of the four repositories (the admin/CRM console) dates to July 2025, with the backend, the doctor patient/prescription app, and the public website following through the rest of 2025 — over a year of continuous, active development across all four services, still being actively worked on.
Technology
- Next.js
- React
- Vue 3
- Node.js
- Express
- MongoDB
- Redis
- OpenAI
- Docker