Frame the system
Map boundaries, clocks, dependencies, data paths and the exact failure before changing behavior.
REAZ ROMEN / ABOUT
I’m Reaz Romen. I work at the seams between systems.
I’m a systems engineer who works across embedded devices, networks, real-time communications, backend services and infrastructure. I’m most useful when a product crosses several of those layers and the problem does not belong cleanly to one team or one tool.
A lot of my work is hands-on: ESP32-S3 firmware and audio, SIP/RTP call paths, Linux and Docker systems, observability, ingress, service control and the glue between them. The same pattern keeps showing up — the symptom appears in one layer while the root cause lives somewhere else.
I prefer evidence over guesswork. I use serial logs, packet captures, timing measurements, metrics, controlled A/B builds and known-good baselines. I preserve working states before changing them, and I document the path so the system can be understood again later.
The part I enjoy most is turning a messy cross-layer failure into a system somebody can reason about.
WHAT I BUILD
Connected firmware, real-time voice paths, Linux infrastructure and operational tooling.
HOW I DEBUG
Known-good baselines, logs, packets, timing, metrics, controlled changes and repeatable tests.
WHERE I FIT
Problems that cross device, network, media, service and infrastructure boundaries.
01 / THE WORKPortfolio →
I do not fit neatly into one engineering box.
That is intentional. A connected product rarely fails according to an org chart. Firmware timing can surface as audio quality. SIP can succeed while RTP fails. A container can be “up” while the service is unusable. I like following the actual data path until the failure makes sense.
Embedded: ESP32-S3, ESP-IDF/ADF, audio codecs, I2S/I2C, provisioning, OTA, controls and board bring-up.
Voice: SIP, SDP, RTP, Asterisk, FreeSWITCH, OpenSIPS, Drachtio, endpoint and media-path debugging.
Systems: Linux, Docker, ingress, observability, service health, logging, dependencies and recovery.
02 / WORKING STYLEServices →
Make it observable
Collect the evidence the system already has: logs, packets, timing, state, metrics and hardware behavior.
Isolate one boundary
Preserve a known-good control and change one part of the path at a time.
Build and retest
Turn the hypothesis into the smallest useful change, then repeat the same failure test.
Leave a trail
Document architecture, verification and recovery so the system is easier to operate after the fix.
03 / WHERE I CAN TAKE OWNERSHIP
01
Connected Device Firmware
Firmware for connected products where the device, hardware interfaces, network behavior and lifecycle all have to agree.
02
Voice & Real-Time Communications
SIP/RTP systems from endpoint behavior through PBX and media paths, including the failures that only appear during real calls.
03
Infrastructure & Operations
Linux and container infrastructure with clear ingress, health, observability, service state and recovery paths.
04
Cross-Layer Debugging
For problems that refuse to stay in one box: audio that is really timing, calls that connect without media, or healthy processes behind broken services.
A FEW THINGS I CARE ABOUT
01 Preserve a working state before “improving” it.
02 Make the system observable before tuning it.
03 Separate confirmed facts from assumptions.
04 Reproduce the same failure after the fix.
05 Leave documentation that survives the person who wrote it.
THE SHORT VERSION
I build, debug and explain systems that cross boundaries.
If you want to understand the kind of problems that means in practice, the case studies are the best place to start.