AalaDoc

The brief

The AalaDoc healthcare platform: appointment booking, doctor-query chat and document storage on Flutter with Firebase. Production runs as a native-feeling mobile app, and aaladoc.com.np is its web entry point - the domain redirects visitors into the app instead of serving a second, thinner copy of the product.

Problem

Aaladoc needed one place for patients and clinic staff to book appointments, ask a doctor a question and keep the documents that follow. The clinic ran that on phone calls, chat threads and paper records, so two people could hold two different versions of the same appointment. The platform also had to work on the phones staff and patients already own, which in practice means mid-range Android devices on unstable connections.

My role

I was the mobile app developer on the Flutter build. I owned the app architecture, the state-management flows, the booking and doctor-query features, the authentication path and the Firebase and REST integrations. Design came from Figma files we iterated together; the appointment and chat screens are the ones I shipped.

Process

• Mapped the booking, chat and document flows against what clinic staff actually did in a working day, then cut every screen that did not serve one of the three
• Split the app into data, domain and presentation layers so the API layer could change without touching the UI
• Built the appointment and doctor-query features first, because those were the two places the old process broke most often
• Added resilient authentication and offline-tolerant reads so a dropped connection showed cached data instead of an error screen
• Tested on mid-range Android hardware with throttled network rather than on a desktop emulator

Result

AalaDoc ships as a Flutter app with booking, doctor-query chat and document storage in one product, and aaladoc.com.np now sends visitors into the app instead of hosting a thinner web copy of it. The layer split is what let the team keep adding screens after the first release without the state logic spreading. There is no published conversion number, so I am not inventing one: the honest result is a live product in clinic use with an architecture the next developer can extend. The booking flow, the doctor-query thread and the document list are the three screens I would keep if the app had to be rebuilt from scratch, and the fact that clinic staff use them daily without a training session is the reason that list is that short.

What it had to do

• Real-time booking, chat and document sync
• aaladoc.com.np redirects into the app rather than duplicating it
• Role-aware screens designed for non-technical clinic staff

Stack

• Flutter
• Dart
• Firebase
• REST API
• Figma