Backend engineer / software architect
My best work starts when a product has real rules but no clean model yet: billing, access, customer state, reporting, invitations, fulfillment, and all the awkward edge cases around them. I find the states, cut the scope, and build the first useful system without pretending the mess is simple.
Selected work
A pattern I am proud of: I have repeatedly been the person to take a vague product or operational need from zero to a first working system. Not alone in the sense that the business context came from nowhere, but alone in the engineering sense: shaping the model, making the tradeoffs, building the first version, and getting it into use.
Current product
A solo product build for a small but uncomfortable customer workflow. The interesting part is not only the generated copy; it is the intake, checkout, entitlement, and fulfillment path around it.
Read the short case studyProfessional systems work
At Checkr, I was the sole engineer responsible for productizing an internal invoice-generation script into a production backend workflow for usage-based billing and finance visibility.
Read the short case studyProfessional systems work
At Divvy Homes, I turned referral tracking into a coherent identity, authentication, and lifecycle workflow around referred customers and magic-link entry.
Read the short case studyAbout
The work I enjoy most sits between product intent and implementation detail. Someone wants a new pricing model, account lifecycle, internal workflow, customer-facing behavior, or reporting view. The hard part is figuring out what the system has to remember, what it has to guarantee, and where it should stay simple.
Outside of software, I spend a lot of time thinking about metaphysics, anthropology, and how people make meaning. I do not pretend those are professional credentials. They are part of the same curiosity: how humans turn abstractions into rules, stories, institutions, and systems.
Working principles
If the product treats two different states as one, the system will eventually leak that confusion.
The first version can be small without lying about what the system must know.
Payment, invitations, permissions, and fulfillment need server-side facts, not hopeful UI states.
Future maintainers should be able to see why the system has the shape it does.
Contact
Send a concise note with the product context, the system pressure, and what needs to become clearer.