Octodoc: from a complex requirement to a live telemedicine product

In 2025, we started working with the Octodoc team on a clear but demanding objective: help bring medical services closer to people in communities where access to a doctor can be limited by distance.

The result is now live. The first Octodoc devices are serving the communities for which they were built, supporting a journey that can include appointment scheduling, guided pre-consultation steps and a video consultation with a medical professional.

For Solandrix, this was more than developing an application. It was the custom development of a connected product ecosystem: the back-office portal, the software used through the Octodoc devices and the application used by doctors. Each part serves a different person and context, yet all of them need to work as one product.

Starting with the service, not the software

The purpose of Octodoc is to make healthcare services more accessible by bringing more of the medical-office experience closer to patients. That purpose shaped the work from the beginning.

Together with the Octodoc team, we clarified the business requirements, the responsibilities of each part of the ecosystem and the technical qualities the product needed to support. Security, scalability and performance were not treated as a final checklist. They were requirements that influenced product and delivery decisions throughout the project.

Product development covered the full operational context of the service, not just the software component. Each user group - patient, doctor and operational team - has distinct needs and workflows, which need to work together in one coherent, efficient experience.

One product, several connected experiences

The ecosystem brings together three main areas:

• the Octodoc device experience used during the patient journey;
• the doctors’ application used to prepare for and conduct remote consultations;
• the back-office portal used to support and operate the service.

The complexity was not simply in building three interfaces. It was in defining what each user needed to see, when information should become available and how the product should respond when a step could not be completed as expected.

The physical setting introduced another layer. A kiosk is not a conventional web application used at a desk. The interface needs to remain clear for people with different levels of confidence using technology. Instructions must be understandable at the moment they are needed, actions must be easy to identify and the journey must account for the devices that are part of the consultation experience.

For doctors, speed and clarity matter for a different reason. The application must support the consultation rather than compete for attention. For operational users, the product must make the state of the service understandable and support the work required around it.

Incremental delivery made adaptation possible

The work was divided into small, usable increments that the Octodoc team could review and test internally throughout the project.

This created a practical feedback loop:

1. agree on the requirement and the expected outcome;
2. design and develop a focused part of the journey;
3. test it in the context of the wider service;
4. adjust the behaviour or experience where the evidence called for it;
5. carry what we learned into the next increment.

That approach mattered because some decisions only become clear when a real flow can be used. Internal testing helped us refine features while change was still manageable, rather than discovering late that an assumption did not hold in practice.

It also kept business, user experience and technical decisions connected. A change in one part of the ecosystem could be considered in terms of its impact on the people and systems around it, not as an isolated ticket.

Engineering for a product meant to operate

Octodoc is a live service, not a demonstration. The engineering work therefore had to account for continued operation and future evolution.

We used enterprise technologies and established engineering patterns suited to the product’s requirements. The principles behind the work are straightforward: keep responsibilities clear, make the system observable and maintainable, protect sensitive information and design each part so the ecosystem can evolve without losing coherence.

Performance and scalability were considered in the flows where responsiveness matters to users and where demand can change over time. Security was approached as a product-wide responsibility, particularly important in a healthcare context. These concerns were balanced with the need to deliver useful increments and learn from testing.

From a shared objective to a service in use

The most meaningful project milestone is not that the software was completed. It is that the product is now being used for the purpose that guided the work: helping the Octodoc team bring medical professionals closer to people who would otherwise need to travel farther for access to services.

Reaching that point required close collaboration. The Octodoc team brought the service vision and domain knowledge. Together, we translated that vision into business, user and technical requirements, made trade-offs visible and adjusted the product as testing produced new information.

We are proud to have contributed to a product with a direct, practical role in people’s lives - and to see the first Octodoc devices now helping their communities.