Curious Engineer · builder · founder
I build systems from the metal up — and ship the products that run on them.
Ten years in, I work across the whole stack, from bare-metal infrastructure up to the products running on it. But building a thing is only where my interest starts. What keeps me curious is everything after: how it behaves in production, how it fails, how you recover it, and how it gets simpler over time instead of more complicated.
That's the throughline. I learn a system by building it, then operating it long enough to actually understand it — the trade-offs, the failure modes, the parts that only make sense once real traffic hits. This site is where I write that thinking down. Not polished answers, but the reasoning underneath, dead ends included.
The question I keep circling lately: how far can you push toward owning the whole stack — running the infrastructure yourself, no managed service to hide behind — and how much simpler things get when you do.
See what I'm building, read the notebook, or find me on LinkedIn, GitHub, and Twitter.
The questions I can't stop turning over. Not domains of expertise — recurring ideas I keep building things to understand better.
I don't really understand a system until I've operated it — watched it fail, recovered it, migrated it. Building is step one; running it in production is where the actual learning happens.
The best infrastructure is the kind no one has to think about. I'm drawn to platforms where onboarding the next user adds almost zero operational work, because the hard parts were solved once, for everyone.
From bare metal up. Running things myself, with no managed service to hide behind — because that's where you find out how they actually work, and what you were quietly paying someone else to worry about.
Complex isn't the same as complicated. A lot of my work is subtraction — collapsing moving parts until what's left is understandable, operable, and hard to break.
Technologies churn every few years; the reasoning underneath lasts longer. I care more about the principles that survive a rewrite than the framework of the month.
The decisions that interest me live where product meets infrastructure — what to build, why it should exist, and how the low-level choices quietly decide what the product can become.
Not portfolio pieces — ongoing experiments, each one live and running. The interesting story isn't the feature list, it's why the thing exists and what building it taught me.
One9x starts from a conviction: good infrastructure should disappear. Nobody should have to think about a server. It runs on bare metal we own, held to one hard rule — every product is operationally serverless, so onboarding the next customer adds essentially zero operational work. That makes it a family of products rather than one, and One9x Pages — static site hosting — is the first of them.
A native Sudoku app, built in Flutter and shipped to the Play Store. The palate-cleanser project — where I put distributed systems down for a while and just ship something people tap on the couch. Proof, mostly to myself, that the same curiosity carries all the way from the metal up to a phone screen.
sudoku.one9x.app →A homelab I run as a personal research lab — the place I validate ideas, simulate production, and understand a technology by operating it myself rather than reading about it. Networking, virtualization, self-hosted services, the works. Most of what ends up in the notebook starts as something breaking in here first.
Welcome to the digital notebook. Less quick-fix, more the reasoning that makes engineering durable. Most entries walk the same path:
Hosting one WordPress site is simple, but what about a million? Explore the architectural challenges and solutions for building a WordPress hosting platform that scales from 1 to 1 million sites without breaking.
Read the entry →