What I can help you build

Workflow implementation: implement or adapt workflow logic in Python, using PyLabRobot, vendor SDKs or APIs within your existing setup.
Instrument and software integration: connect instruments and services to your workflow, with explicit interfaces and failure handling.
Reliability and recovery: make failures easier to diagnose, improve logging, and add retry or reconciliation logic where the physical effects are understood.
Testing and handover: test normal operation and failure cases with mocks or simulations, and document the software for the team maintaining it.

From experiments to software

I started on the experimental side, building wearable biosensors and working in R&D at PKvitality. That experience shapes how I approach software: measurements are noisy, instruments drift, and a successful command does not always tell us what happened at the bench.

Selected work

Merged contributions to PyLabRobot

I contributed structured lifecycle events for plate readers, imagers and thermocyclers to PyLabRobot, an open-source lab automation framework. The merged contribution makes software operations easier to trace while keeping backend completion distinct from physical verification. Review the merged PR.

Real automation logs: what does “succeeded” actually prove?

I audited public Chemspeed and batch-distillation logs to examine what software records establish about physical execution. All 986 Chemspeed operations had matching start and end events, but the reported transfer volumes did not establish an independent measurement of physical transfer. In the distillation data, nearby log activity was not proof of the recovery intervention itself. Audit, data provenance and reproduction steps · Read the analysis.

LabBridge: failure-aware execution and evidence

LabBridge is my open-source project for experimental data and execution reliability. Its fault campaign tests recovery after process termination across 100 seeded synthetic campaigns, checking for lost observations, duplicate acceptances, budget overspends, projection mismatches and package-verification failures. This validation covers synthetic replay infrastructure; it is not a live-instrument result.

How we start

We start with a short call about your workflow and the software change you need. I work within your existing repository and tools. We agree on the scope, access, deliverables and acceptance criteria before implementation, with a first milestone that your team can review and test.

If the scope is not yet clear, the first paid milestone can be a short feasibility study covering the workflow, interfaces, technical unknowns and an implementation plan.

Remote from France with overlap for European and US-East teams. On-site work can be discussed when hardware access makes it necessary.

Software delivery and lab validation

I deliver the agreed software, tests and documentation, including what was validated in software and what still needs physical confirmation. Your automation or applications team remains responsible for the scientific method, hardware configuration, calibration, labware and consumable compatibility, physical safety, bench validation and the decision to put a workflow into production. We identify any additional applications or hardware expertise needed before the engagement starts.

Tools I work with

Primarily Python: async services, FastAPI, Pydantic, SQLAlchemy, pytest and typed interfaces. For lab automation I work with PyLabRobot and can integrate against the interface your project already uses, including vendor SDKs or APIs. I also build agentic and MCP-based systems when they solve a concrete workflow problem.

Software engineering for laboratory automation