I'm a staff software engineer who's spent the past half decade inside the parts of the stack most engineers avoid: billing, payments, and pricing systems that determine what customers actually owe and how they're going to pay.
I didn't set out to specialize in this corner of engineering — I started out building CRUD apps like everyone else. But after landing a role on an international remittance platform, the problems there turned out to be exactly the kind of hard, unglamorous work I wanted to keep doing.

My career has followed the money — literally, across international money transfers, restaurant ordering, and password management. The shape of the work has stayed consistent: architecting and delivering scalable payment systems, migrating critical infrastructure without breaking what's running, and building event-driven integrations that reconcile cash flows and reporting.
What keeps me doing this work is the stakes: get a payments system wrong and it's not just bad UX or a missed opportunity, it's a customer's real money. That constraint makes for some of the most interesting distributed-systems problems I've come across — idempotency, reconciliation, and exactly-once semantics in a world where "exactly once" is rarely a reality.
Outside of work, most of my time goes to Olympic weightlifting — I train five days a week and compete in local meets. Beyond that, I'm usually trying to make the most of Chicago: catching concerts, checking out new restaurants, wandering street festivals, or riding my bike around the city. When I'm not doing any of that, I'm reading history or spending time with friends and family.