Running YOLOv8 inside an Electron surgical guidance app: what I learned building Avail Ortho

Most computer vision tutorials end at the model output. Production medical software is a story about what happens after the model returns its first prediction. The five hundred lines of plumbing between PyTorch and a surgeon looking at an X-ray are where the real work lives.

I led engineering on Avail Ortho, a surgical guidance desktop app that helps clinicians during direct anterior total hip replacement. The system uses YOLOv8 landmark detection on intraoperative imagery, computes leg length delta and offset, and overlays a templated implant on the live X-ray. Below is the part of the build that nobody puts in the README.

Why Electron in a clinical setting

The honest answer is the team. The frontend engineers shipped React every day. The backend was Django with OpenCV and PyTorch. Electron let us put a polished UI on top of a Python runtime without rewriting the model server in Node. The browser engine handles the chrome. A bundled Python child process handles the math.

For clinical software, the model server actually being a server is a feature. The Electron renderer talks to it over loopback HTTP. If the model crashes, the UI stays up and reports the error. If the UI hangs, the model can be inspected independently. Two processes, two responsibilities.

The latency budget

Surgeons do not wait. The whole pipeline from "user dropped an X-ray" to "overlay appears" has a budget of about 600 milliseconds before the experience feels broken. The breakdown we landed on:

• File read + format conversion: 50 ms
• YOLOv8 inference on CPU: 300 ms (we tested GPU but most hospital hardware did not have one)
• Landmark to coordinate transformation: 30 ms
• React render with the overlay positioned: 80 ms
• Buffer for round trip and IPC: 140 ms

The biggest win was switching from a pure HTTP call to a streaming response that started rendering the overlay primitives as they came back, rather than waiting for the full JSON payload.

Bundling Python with Electron without the install pain

This is where most teams give up and ship a separate installer for the model server. We did not have that luxury. The packaging pattern that worked:

1. pyinstaller to bundle the Django backend with its venv into a single folder.
2. electron-builder to ship that folder as a resource of the Electron app.
3. A small Node bootstrapper that spawns the bundled Python on launch and waits on a health check before unblocking the renderer.

The first time the install actually worked end to end, both engineers and the surgeon partners cheered. Onboarding went from "ask IT to install three things" to "double click the installer."

What the medical mindset teaches you

There is no clever in clinical software. There is "the model returned a wrong landmark on this specific image and the surgeon noticed because the leg length number was off by 4 mm." Every prediction has a reviewable artifact. Every change to the inference path comes with a regression set of real X-rays that must pass before the build ships.

The discipline is annoying when you are used to web speed. It is also why I trust the codebase years later. Tests written under FDA pressure are tests that survive.

What this means for remote roles

If your team is building any kind of software where the model is in production and a human makes a decision based on the output, the medical mindset is not a "vertical specific" skill. It is a portable habit. Engineers who learned it ship infrastructure that holds.

---

Md. Tausif Hossain leads engineering at DevTechGuru and ships SaaS independently as TechnicalBind. He is open to remote Senior and Staff roles. Reach him at tausif1337.dev.