[45,000+ Physiotherapists] · [Real-Time Patient Chat] · [Next.js Contract · Aug–Dec 2024]

Overview

Rempleo is not a scheduling tool. It is the system a physiotherapy clinic runs on: patient records, treatment history, orders, subscriptions, billing, staff accounts, and internal support — all in one place. More than 45,000 physiotherapists across France depend on it daily.

At that scale, the product has no room for demo-quality UI. Every list filter, form state, and loading behavior is experienced by thousands of practitioners every week. The platform also has two distinct audiences: the potential customer landing on the marketing site weighing up a switch, and the existing clinician inside the app trying to find a patient record in under ten seconds.

I joined as a contract Next.js developer in August 2024 and spent five months shipping across both surfaces.

The Challenge

Practice management software sits at the intersection of clinical operations and commercial software. Subscriptions need to reflect billing truth, not optimistic guesses. Patient records must stay consistent between what the UI displays and what the server stores. Orders cannot double-submit or leave a clinician in a broken state mid-workflow.

Adding real-time messaging raised the stakes further. A message that appears sent but was not delivered is a worse outcome in a clinical context than in a consumer app. Connection drops, duplicate events, and stale inbox states all needed explicit handling — not error suppression.

On the acquisition side, the challenge was trust. A clinician considering switching their practice management software is not an impulse buyer. The marketing site had to communicate operational credibility before they signed up, not after.

My Role

I worked as a contract Next.js developer across the full frontend scope: public acquisition pages, the authenticated operations dashboard, real-time patient messaging, and technical SEO. I was responsible for both the first impression a new visitor formed and the daily experience of an existing clinician managing their practice.

That dual responsibility — convert the skeptic and serve the power user — shaped every decision about structure, performance, and UI state.

What I Built

Acquisition Pages

I built the public-facing landing routes in Next.js and Tailwind CSS, structuring each page around the specific decisions a physiotherapist makes when evaluating practice software: who is this for, what does it actually handle, and what does switching look like. CTAs and signup flows connected directly to the app's auth layer — no parallel user model, no inconsistency between what marketing promised and what the product delivered.

Core Operations Dashboard

The internal application covers patient administration, order management, subscription state, staff account control, and support-facing tooling. I built and refined the surfaces practitioners use most: finding and updating patient records, handling orders and packages, managing subscription changes, and resolving account issues.

Every flow was designed around repeated, high-frequency use. A clinician who opens the patient list thirty times a day cannot afford a UI that requires three steps to filter to the right record. Load states, error states, and empty states were treated as first-class UI — not afterthoughts.

Real-Time Patient Messaging

I shipped the direct messaging channel between physiotherapists and patients end-to-end on the client. This covered thread rendering, send acknowledgements, real-time subscription to new messages, reconnection behavior on dropped connections, and permission-scoped access to conversations.

Optimistic UI was bounded to what could be confirmed — messages showed a pending state until the server acknowledged delivery. A dropped connection surfaced clearly rather than silently. The inbox updated on new events without polling. Chat sat inside the clinical context, so navigation respected who could see which conversation.

SEO and Performance

I implemented route-level metadata, canonical structure, and semantic heading hierarchies so crawlers read the site correctly. Core Web Vitals patterns — reduced layout shift, non-blocking fonts and images, sensible route-level loading — mattered because 45,000+ potential users discover the product through search and compare it against established incumbents in that first session.

Results

The operations dashboard served 45,000+ active physiotherapists without the regressions that surface at scale — consistent patient records, reliable subscription state, and order flows that handled edge cases instead of ignoring them.

Real-time messaging shipped with connection-aware UI and confirmed delivery, giving clinicians and patients a direct in-product channel instead of spilling communication into unmanaged tools.

The acquisition pages positioned the product clearly for a high-consideration buyer — a practitioner evaluating a switch to their core clinical tool — with load performance and metadata that matched each route's intent.

Closing

Five months. 45,000 users. Two surfaces — one to convince a clinician to sign up, one they relied on every day after they did. The work had to hold up on both.