New foundations, under a clinic that never stopped

Elyops builds the software that surgical teams use to prepare an operating room: the procedure sheets, the instrument kits, the training. In Geneva it was already live, in daily use at a private clinic, and the staff liked it. That was the situation worth taking seriously. The product had grown the way successful early products do: quickly, and in answer to real clinical demand. The company had reached the point where the next few years would ask more of the software than its first version had been built to give. Nothing was on fire. Everything was load-bearing.

Be the technical function. Keep a live clinical deployment running and moving while the company grew around it, then decide what to do about the foundation. Once that decision was made, replace it without the clinic ever noticing.

For two years I was the engineering department. Sole engineer first, then principal, then interim CTO, sitting in the founders’ technical chair.

The first eighteen months were spent inside someone else’s code, keeping it alive and adding to it while it ran in a clinic. That is the unglamorous half of the job. It is also the half that earns the right to the other one, because nobody should be allowed to propose a rewrite until they have paid for the privilege by maintaining the thing they want to replace.

Then we made the call: new frontend, new backend. I wrote the backend alone in 2024, and tested it properly. Security, environments, and deployment came with it. A studio took the frontend, and I had oversight of both tracks and the person responsible for making them one system. Two workstreams, two vocabularies, one product that had to keep behaving the way surgical staff already expected it to.

The decision I am proudest of was the one that made me less necessary. Rather than becoming the person the company could not operate without, I ran the hiring for the engineer who would take the platform on, selected him, handed it over, and worked alongside him through the transition. I stepped back to principal engineer and stayed the technical reference for the platform through to the end of my engagement. Both halves of that are the job. Build it so somebody else can run it, and stay reachable when they need you.

Two things worth hiring for. The first is that a system running in a clinic can have its foundations replaced underneath it, by one engineer, without the people depending on it losing a day.

The second matters more. A technical leader is not measured by how indispensable they make themselves. I built the platform so it could be handed to somebody else, hired that somebody myself, and handed it over. It was documented and tested so that it could be handed on, picked up, and handed on again without depending on any one person’s memory. Continuity was designed in, not improvised. That is the standard I hold every retained engagement to.

CLIENT TESTIMONIAL

« Harivansh est quelqu’un avec qui j’ai eu plaisir à travailler. Il a rapidement compris les enjeux fonctionnels d’un domaine complexe comme le bloc opératoire et a su proposer des solutions techniques pertinentes. J’ai particulièrement apprécié son sérieux, sa capacité d’adaptation, son professionnalisme et sa volonté de toujours trouver des solutions. C’est quelqu’un de fiable avec qui je retravaillerais sans hésiter. »

“Harivansh is someone I enjoyed working with. He quickly grasped the functional demands of a field as complex as the operating theatre, and proposed sound technical solutions. I particularly valued his seriousness, his adaptability, his professionalism, and his determination to always find a way forward. He is reliable, and I would work with him again without hesitation.”

REFERENCE CALL AVAILABLE ON REQUEST