Work

Each entry starts with the problem, then how far down the stack it went, what I changed or decided, and where you can check the evidence.

Investigations and upstream work

Work where the evidence is public: merged compiler changes, retained experiments, and an open-source crate.

Changing what goes inside a Rust rlib

rust-lang/rust · 4 merged pull requests, 1 open

Problem: rustc decided which rlib archive members were Rust object files from their names, which a bundled native library can imitate, and link-only data such as bundled native library filenames was stored with the early crate metadata.
How far down: The compiler backend and the metadata format: the archive writer and reader, the LTO paths of the LLVM and GCC backends, native library handling, and object file sections on different platforms.
What I changed or decided: Added a lib.rmeta-link archive member that only the linking code reads, deleted the filename heuristic, moved native library filenames into the member, and added a cache so each member is decoded once per link. Review reshaped most of the first design.

Read the case study →Tracking issue #138243 →

This site as an engineering laboratory

This website · PERF-001 to PERF-056

Problem: A mostly static site transferred 829 KB on its homepage and fetched a 2.48 MB search index at startup. The question was where that cost came from and how far it could go down without breaking behavior.
How far down: From application code to the bundler, React server and client boundaries, the Next.js router's prefetch scheduler, HTML delivery, the browser's image pipeline, and Chrome DevTools' trace model.
What I changed or decided: Kept the changes that won on the full journey, rejected several that improved a headline metric but made the system worse, and stopped when six experiments planned in advance failed their own gates.

Read the investigation →Experiment folders →

Bitarena: an arena designed for sparse iteration

Original Rust crate · creator and maintainer

Problem: Generational arenas give stable handles, but iterating a long-lived, mostly empty table still visits every hole.
How far down: Memory layout and unsafe code: uninitialized slots, an occupancy bitset scanned a machine word at a time, invariants written down in DESIGN.md, and Miri in CI.
What I changed or decided: Pair generational slots with occupancy bitsets, document where a different data structure is the better choice, and publish the benchmark method next to the results.

Read the case study →Repository →

Professional work

Product and client systems. Where the code is proprietary, the entry stays with what can be said publicly.

Inferal: the engine, the ontology system, and Relay

Inferal · Founding Engineer · current

Problem: Keep data from internal systems and third-party APIs synchronized and modeled consistently, under versioning, pagination, rate limits, partial success, duplicates, and out-of-order data.
How far down: The core engine, the ontology system that gives connected data an explicit model, and Relay, the synchronization capability I built from the ground up.
What I changed or decided: Built Relay from the ground up as the product's data-synchronization capability, and work on the engine and the ontologies it depends on.

The implementation is proprietary, so the case study describes the design pressures rather than the code. My public writing on interrupted execution, retries and reconciliation uses generic examples of the same class of problems.

Read about my work at Inferal →Relay →

MonitorMe: connecting backend traces to what the user saw

MonitorMe · Founder · March 2025 to present

Problem: Diagnosing an incident across microservices needs the backend trace and the user's session in one place.
How far down: Telemetry ingestion with OpenTelemetry, a Go and PostgreSQL API for spans, events and session snapshots, a real-time dashboard, and browser session replay.
What I changed or decided: Built it as an open-source framework, then installed and configured it for client environments through consulting engagements.

Read the MonitorMe case study →Repository →

Financial and healthcare systems

Independent consulting · February 2022 to February 2025

Problem: A latency-sensitive trading and credit platform at Attijariwafa Bank, and secure data processing for anonymization and reporting at Cheikh Zaid Hospital.
How far down: Kafka-backed workflows, multithreading and caching for the financial platform; Go, Node.js and Java services for MedTrack at the hospital.
What I changed or decided: Designed the financial system around its throughput and reliability requirements, and reworked the hospital's legacy ETL into secure AWS Lambda workflows.

Smaller upstream contributions

Front-end compiler fixes, a Deno runtime op, and rust-analyzer changes, each with the problem it solved.

See all merged pull requests →

Earlier engineering work

DICOM Viewer

A browser-based medical image viewer with slice navigation, windowing, zoom, pan, and searchable DICOM metadata.

Go Async Image Processing

A Go worker-pool implementation covering concurrent image jobs, queue management, graceful shutdown, and structured logging.

Looking for more context? Read more about how I work or get in touch.

How I work →Get in touch →