Physio Xpert, Medical SaaS for Physiotherapists

The context

Physio Xpert is a rehabilitation platform for physiotherapists, running in production at app.physio-xpert.com. The practitioner runs a clinical assessment, the platform derives medical flags from it, those flags drive the prescribed exercises, and the patient completes their sessions from a mobile app, reporting tolerance after each exercise.

I designed and built all of it solo since September 2025: the API, the practitioner back-office, the patient mobile app, the data schema, the hosting and the test suite. Three constraints explain nearly every technical decision that follows.

Clinical logic has to evolve without a redeployment. Alert criteria follow practice, not release cycles: they live as data, editable by practitioners themselves from the back-office.

This is health data. Certified hosting, encryption, explicit consent and access traceability form a regulatory frame that is set at design time, not at delivery.

One developer, over time. Every piece has to stay understandable and changeable by a single person five years from now, which rules out over-engineering as much as shortcuts.

The clinical decision chain

This is the piece to understand first: everything else in the architecture exists so that this chain stays correct, traceable and editable without a redeployment.

Two properties of this chain shaped the rest of the work. First, one link is configured, not coded: a practitioner can change their assessments and alert criteria without me deploying anything. Second, the output of the last link feeds back into the first: progression is not a pure function of an initial assessment, it is a state machine accumulating the patient’s history.

Where it started, and why that changed

The product did not begin on the stack it runs on today. The first version was a React + Supabase MVP: a managed database, authentication and access rules provided by the platform, and a front-end talking straight to that database. To validate the clinical decision chain with practitioners, it was the shortest path, and it did its job.

What ended that arrangement was not a technical limit, it was the regulatory frame. As soon as the platform handles real patient records, hosting has to be HDS-certified, and health data requires timestamped consent, explicit retention and a complete access log. Those requirements belong to the server answering every request, not to a client. A front-end querying the database directly has nowhere to put them.

So the migration was not a code move, it was a complete rewrite of the application engine. Everything that lived in Supabase, the schema, the access rules and the clinical decision logic, was rewritten behind a Java / Spring Boot API on a PostgreSQL hosted at Scalingo, the single entry point for both clients. What stayed is the interface: the practitioner back-office is still React, and adding the patient mobile app extended the front-end rather than replacing it.

Carrying out that switch solo, on a product already in use, was the most instructive part of the project. It also explains the shape of the architecture today: if both interfaces only ever talk to the API, it is because the opposite was tried and could not hold up on health data.

The technical choices

The architecture that follows

All 310 API routes live under /api/v1. The back-office and the mobile app update at different rhythms, and an app installed on a phone does not redeploy with a git push: API versioning is not a theoretical precaution here.

What the test suite covers

Working solo changes the method: with no reviewer, the only thing that can contradict a line of reasoning is a test. Coverage is therefore not spread evenly: it is concentrated where a silent mistake would have clinical or regulatory consequences.

The volume is not the argument, quotable as it is: 4,658 tests on the API, whose actual execution I verified rather than just counting. The argument is that none of these areas can change behaviour silently.

What health data demands

Compliance is not a layer added before going live, it is a set of constraints written into the earliest migrations. Consent is explicit, timestamped data rather than a ticked box; deletion is soft, with a 30-day retention window; every read of a patient record is logged. These requirements belong in the schema because an audit log added afterwards leaves a historical gap nothing can fill. Hosting follows the same logic: the platform runs on Scalingo, HDS-certified, in a French region. A certification is a legal prerequisite, settled before it is an infrastructure choice.

The same principle applies to external dependencies. A monitoring tool will happily ship a name or a clinical answer inside an error context, so sensitive data is scrubbed before anything is sent, at the source rather than by filtering downstream.

Where the product stands

The platform is in production and still evolving: a 310-route API covered by 4,658 tests, a practitioner back-office, a patient mobile app on iOS and Android, and hosting on Scalingo, HDS-certified, in France, all maintained by a single person.

Opening it to patients is still ahead. That is also why this page quotes no usage metric: there is none yet, and a volume number in its place would only measure what I produced.

The central bet holds up over time: practitioners evolve their assessments and alert criteria without going through me. That is exactly what the decision engine was meant to make possible.

What the client says