Engineering Notes

When you’re running maintenance across several WordPress sites in sequence, a list view with text-only status doesn’t make “which site is being processed now” or “which ones are already done” easy to spot at a glance. A client put it plainly: “Make it visually obvious in the list which sites are in maintenance and which are finished.“ A colored border is the obvious move, but there are real choices to make. What colors? Where do we get the state from? When does the “done” mark go away? And — can we ship this without touching the backend? This post walks through those four calls and the minimal frontend-only implementation we …

We added a cache-first design to the cross-site updates dashboard, then wired the site-list badge to read from the same cache. Both ships went well. But as soon as it hit real usage, we hit three distinct pitfalls around the cache’s “lifetime” in quick succession: “the badges all disappear on refresh,” “the 7-day TTL is too short,” “running maintenance on one site clears all the badges.” Each is a small spec call in isolation, but from the user’s side, all three feel like the same symptom: “badges aren’t sticking around the way I expect.” This post walks through each fix and what we got wrong. Pitfall 1 — All badges …

In a screen that runs maintenance across multiple sites in sequence, you want to show progress live: a blue border on “the site being processed now,” a green border on “completed sites.” Common UI. The approach we reached for first was “watch the streaming logs the backend emits, and infer which site is being processed.” It turned out to be surprisingly tricky — three rounds of fixes before it stabilized. This post records that trial-and-error as a design log. The first design — “site switched, so mark the previous one done” Logs arrive per-site as lines like [Site name] Starting maintenance. The first implementation was simple: // Initial implementation (later …

One day on our English X account, I posted a link to a fresh blog article and froze when the OGP card rendered: the image was the LP sales banner — “Stop babysitting updates. Start scaling maintenance revenue.” — not anything related to the post itself. Going back through the last seven announcement posts, every single one was showing the same LP sales banner. Articles written as technical engineering deep-dives had been quietly flowing through the X timeline for months looking like sales-promo posts. This article walks through how we found the structural cause and replaced it with a dynamic OGP image generation engine — using our own blog as …

An investigation agent flagged “the license API PHP returns Japanese-hardcoded messages” and we sat down to fix it. But something felt off the moment we opened the file — the version running on the production server didn’t match the latest commit in the local repo. Stranger still, production had more recent features than our local checkout. A bit of digging turned up the truth: months earlier, someone had hot-patched the production file in response to a different user issue, and that change had never been committed back to git. This post walks through how we detected that drift, and the two-stage strategy we used to merge production back into the …

A subtle trap of taking a SaaS international: the system emails sent from your Stripe webhook. Purchase confirmation, renewal success, payment failure, plan change — four kinds of emails triggered by Stripe events. We recently discovered all four had been hardcoded to Japanese for months, sending Japanese receipts and failure notices to English-paying users overseas. The kind of bug that quietly persists forever unless you go looking. This post walks through the currency-based language inference design we landed on, plus the small mb_language trap that nearly ruined the fix. Where do you get “the user’s language” from? — three options There were essentially three design options for picking the email …

For any app past a certain size that’s gone bilingual, the question “how much hardcoded Japanese is still hiding in our repo?” never quite goes away. A naive grep for [ぁ-んァ-ヶ一-龯] returns thousands of hits, and the vast majority are inside translation tables, already-branched code, or comments. The real leaks are buried. For one cleanup pass we attacked this with four parallel AI investigation agents plus AST-based false-positive filtering. The result: ~300 candidates detected → ~60 real leaks → cleaned up across five rounds. This post walks through the flow and the most interesting bug it uncovered — paying English users had been getting Japanese email from the Stripe webhook …

When we shipped a cross-site dashboard in v1.6.2 — a single view that shows plugin-update status across multiple WordPress sites — we hit a UX wall almost immediately. Opening the dashboard meant waiting 24.5 seconds, every time. And the wait got longer as more sites were added. A user put it bluntly: “It launches a heavy operation the moment I open it. I wasn’t mentally prepared for that.” This post walks through the slightly unusual async-UX combination we landed on for that page — cache-first display, explicit fetch, and a “closes-but-keeps-running” notice. What was eating the time Under the hood, the dashboard was running parallel SSH scans against every connected …