Case study
The audit, in full
This is the audit I ran on my own plugin submission, reduced to what is publishable. The plugin is not named and neither are the two names the review team refused, because republishing a name refused for trademark collision is the exact mistake my guide warns against.
What follows is not a list of results. It is a method, and the reason I trust it is that it kept catching things after I was sure it was clean.
The shape of it
- PassesThirteen full review passes over the same codebase, each with a different question
- ElapsedNine days between the first rejection and the final resubmission
- NamesTwo replacement names refused before one was accepted
- Found by readingDead names in markup, a licence webhook asymmetry, a data-loss path, a billing edge case
- Found by runningThree blocking bugs that thirteen passes of reading had not seen
What each kind of pass was for
- Their email, clause by clause. Not a summary of it — the literal text, one clause at a time, treated as a checklist. The most serious residue in the whole audit surfaced here, on the tenth pass, in a subordinate clause I had skimmed twice.
- The brand sweep. Every dead name, not just the last one, including names split across HTML tags and names travelling in a
User-Agentwhere no screen would ever show them. - The SDK calls. Line by line against the vendor's documentation rather than against my assumptions. Three assumptions I held about the licence webhook turned out to be wrong; the documentation said so plainly.
- The business logic. Not "does it run" but "what happens when it half-runs". This pass found a path that could lose user data, and a pricing asymmetry that was a financial risk rather than a technical one.
- The user journey. Reading the plugin the way someone installing it would meet it, not the way its author remembers it.
The part that changed how I work
Thirteen passes of reading missed three blocking bugs. All three appeared within five minutes of actually installing the built ZIP and using it.
What reading found
- Inconsistencies between documents — readme, privacy policy, headers
- Names surviving in places a search does not reach
- Logic that was wrong in a case I could imagine
What only running found
- A service my own notes described as deployed, which did not exist on the hosting account
- An integration that sent a reference to an image instead of the image, so it failed on every site not reachable from the internet — local, staging, maintenance mode
- A missing API parameter that multiplied the cost of every call by nine
None of those three is subtle once you see it. All three are invisible on the page. Reading finds what is wrong; running finds what is missing. They are different searches, and only one of them tells you the truth.
Why I am showing you this instead of a testimonial
I have no client reviews to show for this work, and I am not going to manufacture any. What I can show is the trail: the passes, what each one was looking for, and the fact that the most serious finding came late rather than early.
That is also the honest argument for hiring someone on a submission. Knowing what the guidelines mean took me an hour. Satisfying them took nine days — and the last correction landed one hour before I resubmitted, on a pass I nearly skipped.
I do this for other plugin authors: every point in the rejection email addressed, the guidelines they have not raised yet checked too, and the reply written for you to send.