Notes from building things that hold up
Notes on revenue-critical code, plugin modernization, founder engineering, and products that last.
Almost everything here comes out of the same kind of work: the parts of a product where being wrong is expensive and the failure is quiet. Billing that has to survive a retry, a plugin you cannot take offline because thousands of sites are running it, a decision a founder cannot fully delegate. I write these to think properly about a problem rather than to publish on a schedule, so each one is opinionated, tries to name the trade-off honestly, and says where I would do the opposite. Start with a topic below if you want the argument as a body of work rather than a list of posts.

Boring code is a feature you ship to your future self
Boring code wins on systems that have to last. Why the durable choice looks unimpressive, how to defend it in review, and when to delete clever code.

Six payments edge cases that bite at 2am
Partial refunds, duplicate webhooks, currency rounding, retries, chargebacks, and clock skew: the payments edge cases that page you, with the fix for each.

Shipping a feature into a five-year-old plugin
Real tactics for shipping into an old WordPress plugin: feature flags, backward-compatible DB migrations, and staged rollouts across a live install base.
Building something where this kind of work matters?
I'm in GMT+6 and work async-first, so your timezone is never a reason not to reach out.
Get in touch