End-to-end ownership
I own the local agent and the cloud app, and the typed contract between them — not a UI on someone else’s API.
Diego Turri
Full-stack / Python backend engineer
B.Sc. Computer Science · University of Milan
HealthCam is a local-first computer-vision platform that runs multiple health analyzers in parallel on the same webcam capture. Users choose capabilities such as blink monitoring and heart-rate estimation, while developers can add or replace analyzers without rewriting the surrounding pipeline.
I designed and built it end to end: local Python/FastAPI services, service orchestration, authenticated cloud ingestion, Next.js dashboards, PostgreSQL and deployment.
Python / FastAPINext.jsPostgresDockerCI/CD
Pick a topic
Relevant to full-stack, Python backend, platform and digital-health engineering roles.
Local Python services
Camera capture, app tracking, orchestration and inference are separate local services. OS-dependent components run natively, while dependency-heavy analyzers run in containers.
APIs and a data pipeline
API-key ingest, a Zod payload contract, raw telemetry as the source of truth, and scheduled SQL that fills the insight tables the dashboards query.
Analyzer-agnostic architecture
New inference implementations can be added or swapped without changing orchestration, ingestion or visualization.
Optional deep dive
How HealthCam actually works
HealthCam captures each webcam segment once and sends it to all enabled analyzer services in parallel. Users choose which capabilities to run — such as blink monitoring or heart-rate estimation — while every analyzer can produce structured results for capability-specific insights, alerts and dashboards.
To add an analyzer, a developer starts from a standard service template, implements the inference logic and declares its runtime and capabilities in a manifest. Once the service is registered and enabled, the boot system installs and launches it, while the orchestrator identifies its analyzer capability through the shared registry and includes it in the processing pipeline.
The orchestration layer depends on the analyzer’s external contract rather than its internal implementation. A better rPPG algorithm, for example, can replace an older implementation without changing capture, orchestration or cloud ingestion, provided that it preserves the same contract. A completely new capability can reuse the pipeline but still requires its own product experience or dashboard.
Analyzers can also have very different computational requirements, so HealthCam exposes execution characteristics that help determine which capabilities are practical on a given machine. (under development)
I did not build only a health algorithm. I built the platform around local computer-vision algorithms: one capture pipeline, multiple parallel analyzers, replaceable inference implementations, authenticated cloud telemetry and capability-specific product experiences.