About Me

I build the automation and internal tooling that operations teams run on. Most of my work lives in the unglamorous middle: integrations between platforms that were never designed to talk to each other, workflows that replace something a person used to do by hand, and the small tools a team ends up depending on without ever calling them software.

I got here sideways. I studied IT and business analytics, started in operations support, and learned to code because the problems in front of me needed code and nobody else was going to write it. That's still how most of it goes. Something breaks or takes too long, I build the thing that fixes it, and it's usually in use that same week.

The last few years have been spent inside remote-first companies where the messaging layer is the product surface, which means the interesting problems tend to be about context: getting the right information to the right system at the moment someone needs it, without building a second place for that information to go stale.

What I find most interesting right now is how much ground one person can cover with the current generation of AI tooling. Work that would have needed a small engineering team a few years ago is something I can scope, build, and ship between operational responsibilities. That's not a claim about the tools being magic. It's a claim about leverage, and about knowing which problems are worth solving in the first place, which is the part ops experience actually teaches you.

I work nights from the Philippines, on a schedule that overlaps a team spread across several time zones. Remote-first isn't a preference I picked up recently. It's the only way I've ever worked.

Outside of that I keep a heavily planted aquarium, which is the same job as my day job if you think about it: a system with too many variables, where the fix is usually patience rather than intervention.

The case studies are the evidence for all of the above.