I work close to the thing that breaks.
Not in a planning document three teams away from the problem. I want to be near the request — reading the actual log line, reproducing the actual failure, changing the actual handler.
Five years of e-commerce backends taught me that the distance between you and the incident is the real latency. Workers is the first platform that felt like it agreed with me.
Correctness is not a feature you add later.
Payments, inventory, orders — my whole career has been in the parts of a product where being nearly right is the same as being wrong. A slow system annoys someone. A system that quietly loses an order costs money and trust.
So I design for one owner, one source of truth, and contracts that say what happens when two things arrive at once. Everything else is easier after that.
Five years, mostly spent on order flows.
E-commerce backends: ordering, payment and inventory, plus the services around them. We built most of it serverless on AWS — Lambda behind API Gateway, SQS and EventBridge between the services, Step Functions for the flows that had to survive a failure halfway through, DynamoDB and S3 underneath.
A good part of the work was keeping all of that predictable when the traffic was not. TypeScript, Node and AWS serverless are where I go deep; Cloudflare and the SQL side are newer ground I am still covering.
What I build when nobody asked me to.
Small projects on Cloudflare, written in TypeScript, shipped whenever they are ready. Fewer moving parts, faster feedback, nothing to keep alive at night.
This is where I try the things I would not risk on someone else's production system. Whatever holds up here earns its way into real work later.
Open to backend work.
Remote roles or freelance. If you have something in that area, write to me — I read everything and answer within a day.