The starting point
An existing 2018–2020 healthcare codebase connected two mobile applications to a Laravel API. It needed a modern web experience, an updated mobile foundation and a coherent identity without breaking the contract its clients already depended on.
My work focused on that modernization: the Dovia patient and web identity, Dovia Pro for professionals, a React frontend integrated into Laravel, mobile compatibility work, and regression coverage around sensitive flows. This case study builds on an existing product; it is not a claim that the original application was authored from scratch.
One backend, three clients
Laravel serves the React web application and the API used by both React Native clients. The web frontend can run on the same origin as the API, while patient and doctor roles get different navigation and workflows. Existing endpoint names and response envelopes are preserved across clients.
These are test-suite counts, not a statement of complete end-to-end or production coverage.
A consultation journey people can follow
Patients sign in, confirm their location, search nearby professionals and submit an immediate or scheduled consultation request. Doctors have their own workspace for requests and consultation status. History separates pending, active, completed and cancelled appointments. Profiles, care preferences and medication-request screens share the same identity.
The location should be true, not convenient
A default map centre is useful for display. It is not evidence of where a patient is. The web flow now keeps location empty until GPS succeeds or the user explicitly confirms a point. A late GPS error cannot erase a manually confirmed selection. Doctors can also recover from denied GPS on their pending-request list. Regression tests cover these states, plus local-to-UTC scheduling and daylight-saving gaps.
A usable small-screen flow
The responsive web consultation view was checked at 390px without horizontal overflow. This screenshot shows the web app; the separate React Native applications have their own build and device-verification requirements.
Security work behind the interface
Profile and location updates cannot promote an account into a doctor or change protected identity fields. Generic patient appointment updates cannot rewrite charges or collected money. Payment methods are owner-scoped, and consultation transitions validate the actor and current state.
Billing work includes linking Stripe checkout sessions to the correct subscription, mapping PayPal renewal events through their agreement identifier, and reserving a durable card-charge attempt before contacting the provider. If the outcome is uncertain, the application blocks another capture instead of blindly retrying. Provider reconciliation remains a release gate.
What is demonstrated, and what remains
The screenshots come from the running Laravel/React application using an isolated database with synthetic accounts. Browser checks exercised patient login, location confirmation, nearby search, consultation creation and history, plus doctor acceptance and completion. Automated checks also cover real mobile booking and polling methods in isolation; both Android and iOS JavaScript bundles build.
Development-stage case study. Live payments, email and professional-verification providers still need environment-specific validation. Native-device lifecycle testing, eight propagated image-size dependency warnings per mobile app, push delivery and ambiguous daylight-saving hours remain tracked. Video, chat, pharmacy fulfilment and family accounts are not presented as delivered. No real patient usage or clinical/compliance certification is claimed.
Images and attribution
The app screenshots are actual product captures with synthetic accounts. The illustrative clinician portrait was newly AI-generated for this demo without a reference photograph; it is not a real clinician or an endorsement. September 8 captures replace the earlier portrait whose permission record could not be established.
Maps shown in the screenshots: © OpenStreetMap contributors, with data available under ODbL. The app uses Plus Jakarta Sans under the SIL Open Font License. This asset note is not a blanket copyright or trademark clearance.
What this project shows
The ability to improve an existing multi-client product without hiding its constraints: preserving shared APIs, modernizing the interface, finding authorization bugs and turning those findings into tests another engineer can rerun.