About

What I do

I work on backend systems where correctness, data integrity, and long-term maintainability matter more than surface-level velocity.

• Event-driven systems and analytics pipelines
• Designing developer-facing APIs for consistent data capture
• Background processing and Kafka-based workflows
• PostgreSQL-backed systems operating at large scale
• Building reporting interfaces over slow or complex queries

Professional background

I began working professionally in software in January 2019, initially as a freelancer, and then spent just under five years at a mid-sized internet marketing company with over 100,000 active users.

I joined as a junior engineer and spent my early time delivering features within a constrained area of a large Rails application. As I gained experience, my role shifted toward refactoring and improving existing UI and workflows while preserving backwards compatibility. This work included contributing to and evolving an in-house view component library used across the application.

Later, the company undertook a rewrite of its Rails monolith. I moved onto the events and analytics team, where we designed and built a new event capture and processing system from scratch. The system provided developer-facing abstractions for defining and emitting events, processed those events asynchronously, and streamed them through Kafka for downstream consumption.

That work exposed both technical and organizational constraints. Event definitions were often created without clear analytical intent, and long-term data semantics were not always well defined. The event store itself grew extremely quickly, reaching a scale where querying directly from the primary event table became a bottleneck. While alternatives such as ClickHouse were evaluated, they were ultimately not adopted due to company-level restrictions.

A significant portion of my work involved collaborating with business intelligence teams to reconcile event data with external systems (such as Stripe) so that user-facing reports were accurate and defensible. I also designed and implemented the reporting UI shown to customers. This system was built to tolerate slow queries, support multiple query types, filters, and comparisons, and remain extensible. By the time I was laid off, new report types could be added with minimal changes to existing code. Years later, the reporting interface remains largely unchanged.

Independent work and current focus

After leaving my role in early 2024, I spent time doing independent work outside of software while continuing to develop personal projects. I am now focused on returning to full-time software engineering.

Drawing on my prior experience with event systems, I built EventEngine, a Rails engine that provides a clean, explicit approach to defining, capturing, and processing application events with Kafka integration. It is designed to be dropped into an existing Rails application and used productively within a short setup window, with a strong emphasis on clarity and correctness over convenience.

How I work

I tend to be opinionated about system design, but not dogmatic.

In practice, that means:

• Favoring explicit domain logic over framework magic
• Designing for debuggability and operational clarity
• Treating event data as a product, not exhaust
• Optimizing first for correctness, then for performance
• Accepting constraints honestly rather than pretending they do not exist

I prefer systems that other engineers can reason about months or years later, even if that means less initial novelty.

Outside of work

Outside of software, I value hands-on work and building things in the physical world. That experience has reinforced the importance of fundamentals, sequencing, and respecting constraints—principles that carry directly into how I approach software systems.

Contact

If you'd like to discuss backend systems, event-driven architecture, or potential opportunities, you can reach me here:

• GitHub
• LinkedIn