Medicalib
Medicalib is a SaaS and mobile platform dedicated to healthcare professionals working at home. Its objective? Facilitate the connection between patients and caregivers, while efficiently managing all medical rounds.
Context & project
Patients can create a care request through a dedicated interface, then an algorithm takes care of selecting available healthcare professionals, who then receive the request by SMS. This way, everyone can optimize their rounds and travel.
When I arrived, there were two major missions:
- Eliminate the legacy PHP Laravel to move to an AWS serverless infrastructure and event-driven operation.
- Transform the pricing model to adapt to the needs of the company and end users.
The main challenge was in the complete modernization of the platform without interrupting the service and without losing care requests.
Technologies
Here are the key tools and services used:
| Category | Tech/Services |
|---|---|
| Languages |  |
| Runtime & Infra |    |
| Databases |   |
| Front & Mobile |   |
| Payment & Billing |  |
| Infra as Code & CI/CD |   |
Challenges
-
No downtime
The platform should never be interrupted, at the risk of permanently losing care requests. -
Complete legacy overhaul
The transition from PHP Laravel to a serverless approach was done without service interruption and without functional regression. -
Calendar and rounds management
Implementation of a calendar system to allow healthcare professionals to manage their rounds.A complex challenge, often underestimated, because the calendar concept must take into account many use cases.
Successes
-
Zero interruption CI/CD
Automated infrastructure via Terraform and deployments orchestrated via GitLab to ensure zero downtime. -
Legacy replacement
All inherited code was completely removed and replaced by an AWS serverless architecture without losses or regressions, validating the robustness of the new system.
Failures
- Unintuitive calendar
Despite repeated warnings about complexity, the new rounds management interface remained too far from standards (like Google or Apple). Users had trouble finding their way around.
Lessons
-
Refactoring & Legacy
”Killing” existing code takes time. Before deleting a module, you must have completely recreated all necessary functional building blocks. -
Calendar complexity
Designing a calendar system is never simple. It requires enormous product and UX thinking, because its slightest flaw heavily compromises solution adoption. -
Microservice from scratch
Creating a service from scratch is often easier and faster than updating an existing system. But this requires rigor to avoid fragmentation and maintain global consistency.
Ultimately, this experience allowed me to strengthen my knowledge in serverless architectures and migrations without service interruption. I also touched on the importance of a clear product vision to avoid launching into too big projects (like a calendar) without being fully prepared.
Thank you for reading!