On the Legko platform, a person can train with a trainer online to recover from a serious injury, such as a fracture, faster and without complications.

Building a platform without knowing whether the service will be in demand is a bad strategy. So even before development started, we put together a working prototype based on off-the-shelf tools: Yandex 360 for booking appointments, WhatsApp for messaging with clients, and Kontur.Talk for online meetings.

After launching the working prototype, we started developing the full-fledged platform. We wrote the backend in Django and the frontend in Nuxt and JavaScript. We launched the service in a cloud that complies with local personal data law and allows storing personal medical data.

One of the platform’s key sections is the client dashboard. First, a new user goes through onboarding: they fill out a questionnaire about their condition and the results they want. Sharing medical data requires an e-signature, implemented with a one-time code. After onboarding, the patient can choose a trainer and book their first session.

Plus, the dashboard has everything for convenient work on recovery: a list of scheduled sessions, recovery progress, homework assignments, a chat with the trainer, and the option to attach lab results.

In their dashboard, the trainer keeps something like an electronic medical record for each client. It lists that client’s goals: for example, recovering from a broken arm and improving hip joint mobility. For each goal, the trainer tracks progress, adds notes, and gives recommendations.

The key tools in a trainer’s work are assessment sheets, which we developed together with Legko’s specialists to help track recovery progress. They’re designed so that trainers don’t have to deal with unnecessary paperwork, while the data can still be used to evaluate the recovery work.

The calendar turned out to be one of the most complex features of the project. That might sound strange: a calendar seems like a simple thing built into every device out there. In reality, it raises a whole lot of questions.

• Time zone sync: if a client in Kaliningrad schedules a session for 8:00 PM, for a trainer in Kamchatka it’s 6:00 AM the next day.
• Each hourly slot pulls data from three sources: the recurring weekly schedule, one-off changes (say, the trainer took a day off), and the appointments actually booked. For every slot to show the correct status, the calendar has to correctly process data from all three sources.
• The calendar has to know the current time to dim past events and send reminders on schedule. On top of that, a trainer might travel to another city, and the app needs to catch the time zone change.
• Additional features: drag-and-drop for moving events; day, week, and month views; and color coding for events.

To avoid developing the calendar forever, we focused on a single use case: a trainer needs to see their week, with free and booked slots, and to quickly add and cancel appointments. To make that work, we invested as much as possible in the hard part — time zone math and state resolution.

The component that correctly resolves events took about 500 lines of Vue code. A lot of time went into testing situations where the trainer and the client are in different parts of the country and time zones have to be matched correctly.

The app has a chat where trainers and clients can talk. The hardest part of building it was maintaining the WebSocket connection — a two-way communication channel that delivers messages correctly and quickly. Building a component like that from scratch takes a long time and costs a lot, so we used the open-source Centrifugo and kept only the data storage on our backend.

Training session recordings are stored on an external service and periodically need to be pulled into our own storage. Periodic tasks like this are usually handled with Celery, but it’s a poor fit for large files, so we went with rclone.

It turned out rclone can’t be fully relied on: the service can restart, the task gets lost, and you never find out. So we reworked the module and released the result publicly — now everything is visible, no workarounds needed.

Payments at Legko go through an agency model: the patient pays the platform, and the platform distributes the money among the trainers. Taxes are calculated only on the platform’s commission rather than the full amount — that’s exactly how major services — ride-hailing services, for example — work with independent contractors.

The platform also uses a deferred payment model: the money is charged only when the session starts.

The platform is live, with 12 trainers currently working with clients. Legko plans to develop two more areas: fitness and doctor consultations on lab results.