The Security Review Every RAXXO Tool Passes Before Launch

Why a Fixed Checklist Instead of Trusting Myself

I used to think security was something you kept in your head. Ship a tool, remember the obvious stuff, sanitize the inputs, do not log passwords, move on. That worked until it did not. The moment I stopped noticing was the moment a new feature request pulled my attention somewhere else and an old assumption quietly stopped being true.

The fix was boring on purpose: a fixed checklist that runs the same way every time, regardless of how confident I feel about the code. Confidence is not a security control. A list is.

I did not build this because something went badly wrong in public. I built it because I noticed how differently I treated the same category of risk depending on my mood. On a good day, building a tool I was excited about, I would think through every place user input touched the system. On a day when I just wanted the thing shipped, I would skim the same code and see what I expected to see instead of what was actually there. That gap between a careful pass and a tired one is exactly where real problems live, and it is not something willpower fixes. A list does not have moods. It asks the same five questions whether I wrote the code an hour ago or a month ago, whether I am proud of it or just ready to be done with it.

I run this review on every RAXXO tool before it goes live, whether it is a free give-away like Statusline Builder or a paid subscription. The free ones do not get a lighter pass. A tool that reads a user's terminal config or touches their Claude usage data carries the same risk whether or not money changed hands. Customers cannot tell from the outside which tools got the careful version and which got the rushed one, so I do not let there be a rushed version.

The list itself is short by design. A security review nobody finishes is worse than no review, because it creates the feeling of safety without the substance. Five checks, one sitting, no tool skips ahead to launch without all five marked done. I keep it in the same place I keep the kill switch every RAXXO tool ships with, right next to the pre-launch notes, so it is impossible to reach the publish button without walking past it.

The Five Checks, and What Each One Actually Catches

Input boundaries. Anything a user types, uploads, or pastes gets treated as untrusted until proven otherwise. This is the check that catches the obvious stuff: a file name used to build a path, a config value dropped straight into a shell command, a form field rendered back into a page without escaping. Most of these bugs are invisible until someone deliberately looks for them, which is exactly why a checklist item exists instead of a vague intention to "be careful."

Data at rest. Whatever a tool stores, I ask what happens if that storage leaks. Do I actually need to keep this value, and if I do, is it stored in a form that is useless to anyone who should not have it. The honest answer is usually that I am storing less than I think I need, and cutting a field is safer than encrypting it well.

Data in transit. Every request goes over a connection I would be comfortable having read back to me. No tool phones home over anything unencrypted, and no tool sends more in a request than the feature actually requires.

Third-party surface. Any library, API, or embedded script gets a second look at what it can reach. A tool that imports a dependency for one small function should not hand that dependency the keys to the whole page. This check has quietly killed a few convenient shortcuts over the years, plugins that would have saved an afternoon but widened what a single compromised package could touch.

Failure behavior. What does the tool do when something goes wrong, an API times out, a file is malformed, a user hits it with input nobody planned for. The check is simple: does it fail closed, showing an honest error, or does it fail open in a way that skips a check it should not skip. I have the performance budget every RAXXO tool has to meet for the happy path. This check exists for every other path.

Each item gets a yes or a fix, never a maybe. A maybe is a fail wearing a disguise.

None of these five checks need special tooling or a dedicated afternoon. They fit inside the same review pass where I read through the diff one more time before publishing, the same way I read for typos before hitting send on anything. The point was never to build an elaborate audit process. A one-person studio does not have the hours for that, and an elaborate process that gets skipped under deadline pressure protects nobody. The point was to make sure five specific questions get asked out loud, every time, instead of assumed away.

The Time It Actually Caught Something

Most runs through the checklist are quiet. The code passes, I check the box, the tool ships. Twice this year it was not quiet.

The first time was the third-party surface check on a tool that pulled in a small formatting library for one narrow job. The library itself was fine. What it pulled in as its own dependency was less fine, a package with far broader filesystem access than the one function I needed justified. Nothing had gone wrong yet. The check exists precisely to catch things before "yet" arrives. I swapped the dependency for twenty lines of code that did the one thing I actually needed, and the tool shipped a day later than planned instead of shipping with a wider blast radius than it needed.

The second time was data at rest, on an early build of a tool that logged more of a user's session than the feature needed for debugging. Nothing was exposed publicly, the logs were never accessible to anyone but me, and no customer was ever at risk. But the checklist does not ask "was anyone hurt this time." It asks "does this data need to exist at all." It did not. I trimmed the log before the tool ever reached a real user, and the accessibility pass and this security review now run back to back on my pre-launch checklist, because both are the kind of thing that is invisible until it very much is not.

Neither case was dramatic. Both were exactly the sort of small, boring oversight that a tired evening session produces, and exactly the sort of thing a checklist catches that a good mood does not.

What strikes me looking back at both is how easy either would have been to justify at the time. The dependency saved real effort on a feature I wanted shipped that week. The extra logging felt harmless because I was the only one who could see it, and I was debugging a real issue with it. Those are exactly the arguments that talk a person out of fixing something before it becomes a habit. A checklist does not accept those arguments, because it never hears them. It just asks the same question again on the next tool, and the one after that, regardless of how reasonable the shortcut sounded in the moment.

What Customers Never See, and Why That Is the Point

None of this shows up on a product page. A customer buying a RAXXO tool does not see a badge that says "passed the five-check review," and I have not added one, because a badge is a claim and a claim invites someone to test whether it is true. The review is not marketing. It is the baseline I would want from any tool I paid for myself, applied whether or not anyone is watching.

This is also why the review runs the same way for free tools as paid ones. A free tool is often the first thing a new visitor tries, which means it is the first impression of how the whole studio treats their data. Cutting corners there to save time on something that "does not make money directly" misses the point entirely. Trust is not metered by price.

Running a one-person studio means there is no separate security team to catch what I miss, no second reviewer reading the diff before it ships. The checklist is the closest thing I have to that second reviewer. It does not care if I am tired, behind schedule, or excited to ship. It asks the same five questions every time, and it does not let me answer "I am pretty sure it is fine."

Bottom Line

A security review that lives in your head is really just a hope. Mine lives on a fixed list of five checks, run the same way on every RAXXO tool regardless of price or size: input boundaries, data at rest, data in transit, third-party surface, and failure behavior. It has been quiet most of the time and useful exactly when it needed to be, catching a wider-than-necessary dependency and an unnecessary log before either one reached a real customer.

None of this is glamorous, and none of it belongs on a landing page. It is the part of building alone that nobody sees, right alongside the checklist that decides when a tool is finished enough to launch at all. The tools people actually use are the visible result. The review is just the quiet condition for shipping them with a clear conscience.