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.

You don't rewrite a plugin with a big install base
How I evolve a WordPress plugin with a large install base without breaking users mid-update: a strangler-fig approach with real PHP and version gates.

The first hire who touches your billing should be boring
The engineer who owns revenue early should reach for idempotency, audit logs, and reconciliation by reflex. How to screen for it and reject the rest.

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.
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