Every RAXXO tool goes through the same four-pass check before I call it done, not a different one each time
Pass one is the cold-open test, opening the tool with zero memory of how I built it
Pass three is the break-it pass, where the goal is failure, not success
Consistency, not cleverness, is what actually keeps five different products from feeling like five different quality levels
Why "It Works" Was Never a Good Enough Bar
For a long time, "it works" was the finish line for anything I shipped. I would build a feature, click through it once, watch it do the thing it was supposed to do, and call it done. That bar felt reasonable in the moment because it was true in the moment. The tool did work, for the one path I happened to test, in the one state my own machine happened to be in.
The problem showed up later, always later, in the gap between "it works for me" and "it works." Git Dojo taught me this the hardest way, when I wrote about relearning git from first principles while building it. A lesson that worked perfectly when I clicked through it in order broke the moment someone jumped to exercise four before finishing exercise two, because I had only ever tested the path I expected people to take, not the paths they would actually take.
That gap is not a testing problem in the usual sense. It is a perspective problem. The person who built a tool cannot see it the way someone encountering it cold sees it, because the builder already knows where every button leads. Every assumption that feels obvious to me is invisible precisely because it is mine. I needed something that did not rely on my own judgment catching my own blind spots, because a blind spot that reliably fools you once will reliably fool you again.
So I stopped treating "it works" as a finish line and started treating it as the starting gun for an actual check, the same check, every single time, regardless of how small the tool felt or how confident I was walking in. Running the identical four passes on a five-minute widget and a multi-week product sounds like overkill for the small stuff. It is not. The small stuff is exactly where skipping a pass feels safest and is actually most dangerous, because nobody double checks the thing that looked too simple to need it.
The Four Passes, in Order, Every Time
The first pass is the cold-open test. I close everything, clear my head as much as I actually can, and open the tool as if I have never seen it before, with zero memory of the decisions I made while building it. No skipping to the part I am proud of. No mental notes about what to expect next. If something is confusing to me, someone with total context on the entire project, it will be considerably more confusing to someone with none. This pass alone has caught more real problems than any other single step, because it is the only one that actually simulates a stranger's first five seconds.
The second pass is the edge-input pass. I feed the tool the inputs nobody plans for on purpose: empty fields, wildly long text, special characters, the back button pressed mid-flow, a page refreshed at the worst possible moment. Most software is built and tested against the happy path, the input the builder expects, because that is the input the builder naturally reaches for while working. Real usage does not stay on the happy path, and the gap between the two is where most of the genuinely embarrassing bugs live.
The third pass is the one I actually enjoy the most, the break-it pass. The explicit goal here is failure, not success. I am actively trying to make the tool do something wrong, and I count it as progress every time I succeed, because every way I find to break it is a way a real user will never get to find it first. This pass runs on a completely different mindset than the first two. Passes one and two are trying to use the tool normally and noticing what goes wrong along the way. Pass three is adversarial on purpose, trying to find the seams deliberately instead of stumbling into them.
The fourth pass is the plain-language pass, and it is the one I skipped for years without noticing the cost. I read every piece of text the tool shows a user, out loud, and ask a simple question of each line: would this make sense to someone who has never talked to me about this project. Internal shorthand creeps into interfaces constantly, a label that made sense in a planning conversation weeks ago but means nothing without that context. This pass catches the words, not the logic, and it turns out the words matter just as much as the logic for whether a tool actually feels finished.
What Consistency Buys That Talent Alone Cannot
Here is the part that took me the longest to actually internalize: the value of these four passes is not in any single one of them being clever. None of them require special skill. A cold-open test is not a sophisticated technique, it is just discipline applied at the right moment, before the shipping decision instead of after. The value is entirely in running the same four, in the same order, every time, regardless of how the tool feels going in.
Without that consistency, quality checking quietly turns into a mood. On a day I feel confident about something, I would skip straight to a quick click-through and call it good enough, because confidence feels like evidence when it is not. On a day I feel uncertain, I would test far more thoroughly, which sounds responsible until you notice the actual problem: the amount of scrutiny a tool gets should depend on the tool, not on how I happen to feel that morning. A fixed process removes my mood from the equation entirely, and that is the whole point of having one.
This is also, I think, the actual reason five different products from a one-person studio can feel like they belong to the same studio instead of five separate experiments. Git Dojo, Statusline Builder, OhNine, and everything else I have shipped are different tools solving different problems for different people, built at different times with different amounts of confidence going in. What they share is not a visual style or a shared codebase. It is that every one of them passed through the exact same four checks before I called it finished, which means the floor under all of them is the same floor, even when the tools themselves have nothing in common.
I have come to believe consistency is underrated compared to cleverness in almost every part of building things alone. A clever one-off check might catch more on the day I think to run it. A boring, repeated, unglamorous four-pass routine catches more across a year of shipping, because it does not depend on me thinking of it fresh each time. It depends on nothing except actually doing it, which is a far lower bar to clear reliably.
Where the Process Still Fails Me, and What I Do About It
I want to be honest about the limits of this, because a four-pass routine is not a guarantee, and treating it like one would be its own kind of mistake. The cold-open test gets weaker every time I run it on the same tool, because true zero-context is only available once. By the third or fourth round of testing the same feature, I am not actually approaching it cold anymore, I am approaching it with fading memory instead of none, and fading memory still shapes what I notice and what I skip past.
The fix I use is not perfect, but it helps: I let real time pass between building and testing whenever the schedule allows it, a day if I can manage it, even a few hours if I cannot. Distance does more for genuine fresh eyes than effort does. Testing immediately after building, no matter how deliberately I try to forget what I just did, is testing with the context still warm, and warm context is exactly the thing the cold-open pass is trying to strip away.
The other honest limit is that four passes from one person is still one person's judgment, four times over, not four different people's judgment once each. I do not have a second set of eyes checking my blind spots the way an actual team would, and I am not going to pretend a solo process closes that gap entirely. What it does is close the gap that is actually closeable alone, which is the gap between careless and careful, even if it cannot close the gap between one perspective and several. Knowing exactly what a process cannot do is as useful as knowing what it can, because it tells me where to stay humble about a tool even after it has technically passed.
Bottom Line
Four passes, cold-open, edge-input, break-it, plain-language, run in that order on absolutely everything I ship, no exceptions for the small stuff. None of the four are individually clever. What makes them worth anything is that they run every time, on every tool, regardless of how confident I feel walking in, because confidence was never actually evidence that something was ready.
The real shift was not learning new testing techniques. It was accepting that "it works" was a description of one path through the tool, not a verdict on the tool itself, and that the gap between those two things is exactly where a stranger's first real experience with anything I build goes wrong. A boring, repeated process closes more of that gap than a burst of last-minute cleverness ever has for me, and it is the reason I trust what I ship now more than I trusted it a few years ago.
Top comments (2)
"Confidence was never actually evidence that something was ready" is the whole thing in one line — and break-it is the pass I'd protect hardest, because it's the only one of the four that doesn't rely on you being right.
The limitation you already named — fading memory on repeat, single-perspective bias — is the exact wall I hit running a manual break-it pass on everything. My imagination for how to break it was the bottleneck, and I stopped seeing the same failure after the third pass through. What fixed it wasn't a better pass, it was freezing the break: every failure I ever induced by hand became a planted fixture the system re-runs itself, so break-it no longer depends on me remembering to be adversarial today. The four-in-order discipline is right; I'd just move break-it from a thing you perform to a thing that's recorded — because the performed version degrades quietly, exactly as you said it does.
Cold-open and plain-language don't automate as cleanly; those genuinely need the human who's never seen it. But break-it was the one silently getting weaker every time I trusted myself to run it fresh.
Great! I hope you will write even better articles in the future.