Why I Use Every RAXXO Tool Myself Before Anyone Else Does

The Tool I Shipped Without Ever Really Using It

The mistake happened early, before I had the habit that fixed it. I built the first version of a small utility, ran through the obvious paths by hand a few times, watched it behave the way I expected, and shipped it. I did not sit down afterward and actually use it for the task it was meant to solve. I had tested it. I had not used it.

The difference showed up about a week later. A setting that worked fine in isolation turned out to conflict with a default I had picked earlier in the flow, and the conflict only appeared if you touched both in the same session, in a particular order, which is exactly what a real user does and exactly what a quick manual test does not. Someone wrote in confused about behavior that looked like a bug because it was one. I could not reproduce it at first, because reproducing it meant using the tool the way someone actually would, start to finish, under a bit of time pressure, instead of poking at individual features one at a time.

That was the moment the rule changed. Since then, nothing ships from this studio until I have used it myself, for real, for the actual job it exists to do, not a demo version of that job.

I still remember how small the actual fix turned out to be once I found it, a couple of lines, nothing that would have taken more than a few minutes to change. What took longer was accepting that the process that let it through was the real problem, not the specific bug. A different bug would have slipped through the same gap next time, because the gap was never about that one setting. It was about the fact that I had confirmed the pieces worked without ever confirming the whole thing worked together, under the kind of real, slightly impatient use it was actually built for.

What "Using It Myself" Actually Means

This is not the same thing as testing, and I want to be specific about the difference because it is easy to convince yourself you are doing one when you are only doing the other. Testing is running through a checklist: does this button work, does this field validate, does this export produce a file. Using a tool is putting it between you and a real task you actually need done, and then living with whatever friction that creates.

Git Dojo exists because I wanted a way to actually drill git commands instead of looking them up every time, so before I called it finished, I ran real lessons on myself in real terminal sessions, the same ones I use for actual project work, not a sandboxed demo account. That is where I found that a level I had designed to feel encouraging actually felt patronizing once you had already cleared the level before it twice. A checklist would have confirmed the level worked exactly as designed. Using it told me the design itself was wrong.

OhNine is the clearest example, because the entire premise only proves itself under pressure. A usage tracker that alerts you before you hit a session limit is worthless if you build it, glance at the number once, and move on. I had to actually run heavy sessions with it sitting in my menu bar, ignore it the way I would naturally ignore any small notification while deep in a task, and see whether the alert actually cut through that ignoring. The first version did not. The threshold fired at a point where I was already too deep into a task to want to stop, which meant the alert existed but did not actually help anyone. That only shows up if you are the kind of person who gets absorbed in a task and forgets to check, which is exactly the audience the tool is for. A checklist test does not get absorbed in anything.

The Limits of Testing Something Only on Yourself

I want to be honest about where this habit runs out, because dogfooding on your own has a real ceiling and pretending otherwise would be its own kind of dishonesty. I am one user, with one way of working, one operating system most days, one level of comfort with a terminal that most people who buy Git Dojo explicitly do not have yet. Using a beginner tool as someone who is not a beginner anymore tells me whether the mechanics work. It tells me almost nothing about whether the tone lands, whether the pacing feels right to someone actually learning, or whether an instruction that reads as obvious to me reads as confusing to someone encountering the concept for the first time.

That gap is why using something yourself has to be the floor, not the whole process. It catches the bugs that only show up under real, sustained use, the kind no checklist thinks to check because the checklist author already knows how the tool is supposed to behave. It does not replace watching or hearing from someone who has never seen the tool before, who does not know the shortcuts, who will hit the exact confusing wording you stopped noticing weeks ago because you wrote it. I still need that second kind of feedback for anything meant for someone less technical than I am, and I have learned not to treat my own comfortable, repeated use as a stand-in for it.

There is also a specific blind spot that only shows up after enough repetition, which is that I stop seeing my own tools as new. By the third or fourth real session with something I built, I already know every shortcut, every place a menu is one level deeper than it should be, every label that only makes sense because I know what it is short for. That familiarity is exactly what makes my own use unreliable past a certain point. It tells me the tool works for someone who already understands it, which is the one thing I never needed proof of. So the habit is not "use it once and move on," it is "use it early, before the familiarity sets in, and then bring in someone who has none of that context before calling it finished."

How This Changed What I Actually Ship

The most direct effect is that fewer things break after launch, because the bugs that used to surface as support messages now surface during my own use, before anyone else ever sees the tool. That sounds obvious written down, but it took actually living through the alternative, shipping something untested by real use and watching a real person hit the gap, to make the rule stick instead of staying a nice idea I meant to follow.

The less obvious effect is on pace. Using a tool properly before shipping it takes real time, more than a quick pass of manual testing does, because you cannot rush a genuine work session the way you can rush through a checklist. Evenings and weekends do not stretch to fit everything I would like to ship, and this rule means some things take longer to go out the door than they would if I skipped straight from "it works" to "it's live." I have made peace with that trade. A tool that goes out a bit later having actually been used is worth more than one that goes out on time and needs a fix within the first week, because the fix costs more trust than the delay ever did.

It also changed how I read my own bug reports, or the near total absence of them for tools I put through this properly before launch. When something is used for real before it ships, most of what comes back afterward reads like polish requests instead of "this is broken" messages. That shift, from bug reports to feature requests, told me more about whether the habit was actually working than any internal review ever could.

It changed one more thing I did not expect going in, which is how I scope a tool in the first place. Once you commit to actually using something for real before it ships, a feature that sounds good on paper but that you would never personally sit through gets cut earlier, because you are the one who has to sit through it first. A few ideas that looked reasonable in planning did not survive contact with an actual work session, not because they were technically broken, but because using them myself made it obvious nobody would bother. That is a cheaper place to lose a bad idea than a support inbox six weeks after launch.

Bottom Line

The rule is simple to state and harder to actually follow: nothing leaves this studio until I have used it for the real task it exists to solve, not just tested that its parts individually work. That single habit catches an entire category of problem that only shows up under real, sustained use, the kind a checklist is structurally unable to find because it only ever exercises what the checklist author already expects to check. It is not a substitute for hearing from people who are nothing like me, and I try to stay honest about that limit instead of pretending my own comfortable use covers everyone. But as a floor before anything ships, it is the single habit that has done the most to keep the gap between "it works" and "it works for someone actually using it" as small as I can make it.