Aviz Health

01 The problem, and everyone it had to work for

Healthcare doesn't fail because hospitals lack doctors. It fails in the gaps: booking an appointment takes phone calls, lab results live on paper, pharmacies guess at prescriptions, and when someone dials for an ambulance, dispatch runs on hope and shouted phone calls.

Aviz Health exists to close those gaps. But closing them means serving four groups of stakeholders whose needs actively fight each other:

• Patients, want care in three taps. They don't want to learn software; they're already having a bad day.
• Verified partners (doctors, hospitals, labs, pharmacies), want schedule control, clean incoming requests, and zero ambiguity about who's coming and when.
• Ground operations, the "Heros" (nurses, drivers, delivery agents), need task-first, glanceable interfaces that work one-handed between stops.
• Admins, need god-view: live operations dashboards, partner verification, and the ability to intervene when the machine misbehaves.

Designing one coherent product for all four was the actual job. The code was the easy part, by comparison.

02 My role

I owned the entire technical surface. Architecture, UI/UX systems, three native mobile apps, the web command center, the API layer, data modeling, third-party integrations, and release engineering. No handoffs, no translation losses, when the ambulance dispatch flow needed to change at midnight, the person changing it was me.

03 Designing for four kinds of users

One design language, four dialects:

04 Engineering the ecosystem

The whole platform lives in one monorepo (aviz_health), three Flutter apps, the admin dashboard, a shared types package, and the backend under one roof so a protocol change propagates everywhere atomically:

aviz_health/
├── aviz_admin/     # Next.js 16 admin dashboard (HeroUI, Recharts, Zustand)
├── aviz_user/      # Flutter patient app
├── aviz_partner/   # Flutter doctor/hospital app
├── aviz_heros/     # Flutter ground-staff app
├── backend/        # Bun + Hono TypeScript API
└── shared/         # Shared types/configs

• Backend: Bun + Hono + TypeScript over MongoDB/Mongoose, with Redis caching in front of hot paths, matching, booking, and dispatch stay responsive under load.
• Real-time everything: live user-partner matching, appointment state machines, and the ambulance SOS dispatch pipeline built for zero lag, because in this domain, latency isn't a UX nitpick, it's the product.
• Integrations: Agora RTC for video consultations, Cashfree for payments, Google Maps for location and routing, Firebase Auth for identity across all four apps.

05 Shipping it

Four surfaces, one release cadence. The monorepo keeps versions in lockstep, a shared-type change lands everywhere together, which is how you avoid the classic multi-app death spiral where the patient app speaks v2 and the backend only understands v1.7. Aviz is live on Google Play today as version 2.0, with the admin console and partner tooling running in production alongside it.

06 What it proves

Case studies love numbers; most of mine here are contractual, not public. So read this section as a capability manifest instead:

• Took a healthcare platform from empty repo to consumer-grade Play Store release, v2.0, across four applications.
• Designed one UX system flexible enough for patients, clinicians, and field crews without fragmenting into four unrelated products.
• Built the real-time backbone, matching, booking, SOS dispatch, that the whole value proposition hangs on.
• Integrated the hard third-party surface area (RTC video, payments, maps, auth) that turns demos into products people rely on.

07 What I learned

Three things stuck: first, in healthcare, the ground-staff app deserves as much design love as the glossy patient app, the nurse using it 200 times a day is your power user. Second, Redis in front of MongoDB is cheap insurance against the exact traffic spike you didn't model. Third, monorepos aren't a trend accessory; with four synchronized apps they're the difference between shipping and archaeology.