Engineering . 5 August 2026
Built in the open, including the bugs
What it takes to ship a plugin that has never run on a live install, and the four bugs the test suite found that reading the code did not.
7 minute read
This product is a WordPress plugin, which means it has to work on somebody else's hosting, with somebody else's theme, on a PHP version chosen by a hosting company. There is no staging environment shared between us. So most of the engineering effort has gone into being able to prove things without one.
What gets checked before anything ships
- The scheduler has its own harness. The forgetting curve, the interval growth, the effect of a lapse and the learning steps are all asserted against hand-computed values, so a change to the maths cannot pass quietly.
- The content has a consistency harness. Every story's vocabulary has to resolve to a real entry in the word list for that language. Every hook has to point at a word that exists. Duplicates fail the build, because a duplicate is silently skipped on import and then somebody wonders why a word is missing.
- The front end is driven in a real browser. Against a mock of the REST layer, clicking real buttons.
- Every page of the website is driven in a real browser too. Contrast is measured rather than eyeballed, on every band, on every run.
Four bugs that only a browser found
The editor that ate the title
The memory palace editor rebuilt itself from the saved record whenever a room was added, which threw away the name you had just typed and had not saved yet. Perfectly reasonable code. Completely broken behaviour.
The invisible button, twice
A base style with two classes out-specified a variant with one, so every primary button rendered as an ordinary one. It was fixed, and then the identical mistake happened again on the website with a link colour reset. The lasting fix was to write the reset at zero specificity and then measure the actual colours of actual buttons on every test run, because a bug that has happened twice will happen a third time.
The table that widened the page
A wide table inside a scrolling container still made the document itself wider in Chromium, so several pages scrolled sideways on a phone even though nothing was visibly cut off. One line of CSS fixed it. Nothing but a real browser at a real width would have found it.
The tooltip that killed itself
Tapping a word in the story reader scrolled it into view, the scroll handler saw a scroll, and the handler closed the tooltip that the tap had just opened. It looked like a tap that did nothing.
The thing tests cannot do
None of this proves the plugin installs cleanly on a particular host, that the schema builds against a particular MySQL, or that a membership plugin is wired correctly. Those are checked by installing it on a staging subdomain and watching, and there is no substitute.
More from the workshop
Why a picture beats a translation
The keyword method has been studied since the seventies, it works in every language pair anyone has tested, and almost no software builds it in properly.
Read itMethodHow the schedule decides when to ask
Every card carries two numbers. Between them they work out the day your memory of that word falls to ninety percent, and that is the day it comes back.
Read itPracticalWriting hooks that actually stick
A practical guide, with the five rules, the three traps, and worked examples in four languages.
Read itTry the thing this is about
Thirty days free, no card, and the hook library is open before you make an account at all.