Back to workHealthcare platform

Clinify

A role-aware clinic system for appointments, consultations, records, and real-time patient communication.

  • React / Vite
  • Node / Express
  • MongoDB
  • Agora

A clinic has
more than
one viewpoint.

Patients, doctors, and administrators need different things from the same system. Clinify brings appointments, clinical records, and consultation tools into workflows shaped around those roles.

The Gynae Care Center homepage: a booking hero, clinic photograph, and appointment call to action.

The patient’s way in

Clinify’s patient-facing build for Gynae Care Center in Lahore: booking, services, and clinic information. Capturing this build does not measure production usage.

Local release build, captured September 2026
Clinify's public FAQ page listing patient questions about appointments and consultations.

The public surface

Everything a patient can reach without an account. The clinical workflows sit behind role-aware authentication and are deliberately not pictured here.

Production build, captured September 2026

One appointment, end to end

Booking a slot, traced through the running system.

HTTPSapi.*:5000PatientBrowserReact SPAVercel edge / CDNNginxTLS · reverse proxyExpress 5Node · supervised by PM2MongoDB AtlasManaged clusterAgora CloudWebRTC video · RTM chatGmail SMTPNodemailer

The SPA is served from Vercel's edge. The frontend and backend ship through two independent pipelines — Vercel auto-deploys on push, the API is released by hand onto EC2.

Decisions.
And their cost.

Role-aware access control

More backend policy work in exchange for clearer clinical boundaries.

Token-authenticated real-time consultation tooling

External SDK complexity in exchange for managed video and chat sessions.

Separate patient and practitioner workflows

More interface states to maintain in exchange for a focused experience for each role.

What's
in the system.

  • Role-based access for patient, doctor, and admin workflows
  • Agora chat and token renewal integrated
  • MongoDB persistence with input-safety middleware

What this
proves. And
what it doesn't.

  • True within a stated scopeA running patient-facing build for Gynae Care CenterTrue within a stated scopeLocal release build, captured September 2026The patient-facing build is branded for Gynae Care Center in Lahore. The screenshot comes from that running build; it does not independently establish current production usage or deployment health.
  • Verified in sourceRole-aware access enforced in backend policyVerified in sourceClinify repositoryPatient, doctor, and admin paths are enforced in backend policy, not hidden in the interface.
  • Verified in sourceReal-time consultation with token refresh and a REST fallbackVerified in sourceClinify repositoryAgora chat with token refresh, typing events, and a REST fallback when sockets drop.
  • Verified in sourceRate limiting, Helmet, and NoSQL sanitization in the request pathVerified in sourceClinify repositoryRate limiting, Helmet, and NoSQL input sanitization are in the request path.
  • Not yet provenScale, uptime, and latencyNot yet provenNot instrumentedUptime, API latency, and tenant count are unmeasured. The patient figures shown on the clinic's own homepage are its marketing numbers, not engineering measurements I have taken.

The next
hard question.

The next iteration should make operational observability as deliberate as the application architecture.

Next: Materna