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

What each kind of pass was for

  1. 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.
  2. The brand sweep. Every dead name, not just the last one, including names split across HTML tags and names travelling in a User-Agent where no screen would ever show them.
  3. 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.
  4. 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.
  5. 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.

If your plugin is held right now

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.

What that involves