Selected Projects

Below is a curated selection of projects that better represent the work I have done in professional environments across Linux systems, edge devices, cloud infrastructure, messaging, observability and operational tooling.

Edge device connectivity and Bluetooth platform work

Bluetooth service layer for medical and field devices

A recurring part of my work has been building the software layer that lets Linux-based devices discover, pair with and communicate with Bluetooth peripherals in production.

Part of that work involved building a Bluetooth service intended to replace parts of the standard bluetoothd behavior with a DBus-accessible service tailored to the needs of device-side applications. It included session handling, pairing delegates, device abstractions and service control logic, which reflects the kind of engineering that sits very close to Linux internals and real hardware behavior.

Another part focused on scanning for specific BLE devices and exposing detections over DBus so other services could react in a structured way. That kind of work sounds small on paper, but in production it means dealing with flakiness, discovery timing, integration boundaries and the operational reality of physical devices in the field.

Messaging and distributed communication for hub devices

Matrix, MQTT and hub messaging infrastructure

One of the more interesting backend/system integration areas I worked on was messaging infrastructure for connected hubs.

The design bridged backend messaging systems and constrained field devices by combining Matrix-style room messaging with MQTT and hub-specific identity logic. Hubs logged in with generated identities, joined room-based channels and exchanged messages through a service that coordinated registration and transport between messaging layers. This is a good example of work that is not just backend or infrastructure in isolation, but the practical design of distributed communication systems.

Related work extended that model into a patient and nurse communication workflow with state tracking, message clearing semantics, synchronization behavior and operational concerns around notification delivery. I like this kind of system because it forces careful thinking about data flow, event ordering, reliability and user-facing consequences when something goes wrong.

Device-side APIs and local service integration

DBus and MQTT driven device control APIs

Another recurring theme in my work has been the glue code that makes complex device platforms usable. That includes APIs and service layers exposing supported MQTT messages, local service behavior and BLE-related operations on connected hubs.

This sort of work is easy to underestimate, but it is often where systems either become operable or become painful. It requires designing clean boundaries, handling imperfect inputs and building something that other services and operators can rely on without having to understand every implementation detail underneath.

Operational tooling and supportability

Tooling for diagnosis, workflows and support

A lot of important systems work does not look glamorous from the outside. A significant part of my engineering has gone into collecting useful state, automating repetitive workflows, supporting diagnosis and making distributed systems easier to operate.

This is the kind of work I value a lot because it reduces toil and improves recovery when incidents happen. In fast-moving environments, reliability often comes less from one heroic subsystem and more from the supporting tooling that makes problems visible, actionable and repeatable.

Embedded Linux and device platform foundations

Linux systems close to hardware and OTA-style operations

Another strong theme in my work has been system-level engineering close to the operating system, device configuration and update or integration mechanics.

This is the territory where embedded Linux, Android-adjacent behavior, device configuration, field upgrades and service orchestration meet. I have spent a lot of time in exactly this layer, where the work is neither pure firmware nor pure cloud, but the complicated interface between them.

Data presentation and product-supporting system components

Charts, rendering and application-support infrastructure

I have also built product-supporting components that translate backend behavior into something usable by applications and users, including chart generation, rendering workflows and application-facing integration layers.

These projects are useful evidence that my work has never been confined to a single narrow box. I have often moved between infrastructure, backend logic, device services and application-facing integrations, depending on what the system actually needed.

What ties these projects together

The common thread across all of them is not a favorite language or a single framework. It is a type of engineering problem: systems that have to work across boundaries, under real operational pressure, with enough reliability that other people can depend on them. That usually means Linux, debugging, edge devices, cloud infrastructure, messaging, automation, observability and a willingness to get into the uncomfortable parts of a system until they behave.