I care about what happens after the code ships.

Engineering philosophy

Correctness, then clarity, then speed — in that order.

Most software is read and changed far more often than it's written, so I optimize for the engineer who shows up six months later: clear boundaries, obvious data flow, and failure handling that's visible instead of hidden. Speed matters, but it's the last thing I trade correctness for — never the first.

Why building systems matters

If payroll is wrong, someone doesn't get paid.

I'm drawn to systems where the stakes are concrete. A double-charge isn't a failed test — it's someone's money. A missed payroll run isn't a ticket — it's rent. That framing changes how I design: I assume the network will fail, the processor will be late, and the rare edge case will happen on a Friday night. My job is to make the system behave predictably anyway.

From frontend to full-stack

I followed the problems past the API boundary.

I started on the frontend, close to users and interfaces. But the problems that held my attention kept living on the other side of the API — in data models, consistency, and how state actually moves through a system. So I followed them. Today I build the whole path: the interface a merchant trusts, the endpoints behind it, and the data layer that has to stay correct under load.

How I work

I write the decision down before I write the code.

Before the first commit I answer a few questions in plain language — what are the boundaries, who owns this data, how does it fail? Writing it down turns vague intentions into decisions I can defend and revisit later. I default to boring, observable technology, keep systems only as complex as the problem demands, and would rather ship something correct and legible than clever and fragile.

Principles

Currently open to senior software engineering roles.