I make sense of hard technical problems.
Software consulting: implementation and advisory.
I ask "why?" until I get to an understanding of the problem, situation, or solution. This enables me to get to the core of any problem, and assess whether the proposed solution is the right one.
This applies at every level: in a codebase, in a meeting, in a system that's behaving unexpectedly. It's how I find bugs that have resisted being found, and how I redirect projects that are going sideways before too much is built in the wrong direction.
I put the "full" in fullstack: backend, frontend, databases, infrastructure - I've done it all.
My core experience is in web and application development. Some of the most interesting problems have taken me deeper: Postgres extension development, logical replication internals, memory safety, FFI, and performance engineering.
Joined an in-progress project to build a Kafka-to-Postgres integration and found the team working under core technical misunderstandings about transactional consistency. Cut scope, redesigned the message processing loop for correctness, restructured the control plane architecture, then did profile-guided performance work to reduce CPU consumption in hot paths.
Built a conversational AI training platform for triathletes from scratch - training plan generation, athlete performance assessment, LLM-as-a-judge evaluation suite. Surprisingly the hardest part was coercing LLMs to handle dates correctly.
Developed migration methodologies and tooling for moving data into TimescaleDB with correctness guarantees. Migration is the kind of work where getting it wrong has real consequences - so the emphasis was on reliability over cleverness.
A routine PostgreSQL version upgrade surfaced two bugs nobody had been able to track down. I picked it up unprompted, navigated through layers of opaqueness and Rust macros, and found two separate root causes: unaligned slice access triggered by new Rust 1.78 safety checks, and a serialization function operating on the wrong type.
Traced unexpected memory usage in a service into the depths of a third-party Go library. A mitigation for malformed data was causing values to be stored in grossly oversized buffers.
Profiled memory usage in a service using this library as a dependency, found it was allocating gigabytes dynamically where fixed-size buffers would do. Replaced dynamic allocation with a pre-allocated buffer pool. Reduced allocation from gigabytes to megabytes, CPU time by 50%.