The RAXXO Tool I Killed Before It Ever Shipped

The Tool That Almost Shipped

Every RAXXO tool that made it to raxxo.shop has a public story: what it does, why I built it, who it is for. There is one that does not, because it never got that far. I built most of it anyway, past the point most people would call a prototype, close enough to a real product that I had already started sketching what the page would say.

The idea came out of my own workflow, the way most RAXXO tools do. I noticed a small piece of friction I kept hitting, built a rough fix for myself, and the fix worked well enough that the obvious next thought was: other people probably hit this same wall. That thought has led to every tool I have actually shipped. This time it led somewhere else.

I kept building anyway, past the point where I should have stopped to check the assumption. The interface got a real pass. The core logic worked reliably, no crashes, no edge cases I hadn't already caught. I even opened a blank file and started naming sections the way I do for everything else, which is usually the last step before something becomes real enough to sit next to the other four products. It was close. Closer than I am comfortable admitting, looking back.

What stopped it was not a bug, and it was not boredom. It was a question I finally forced myself to answer honestly, months into treating the tool as inevitable: who, specifically, other than me, actually has this problem badly enough to open their wallet for a fix. I could not answer it with a real person. I could only answer it with a version of myself, and a version of myself is not a market.

The Test I Wish I Had Run Sooner

The test I use now is short enough to write on one line: describe the exact moment a stranger, not me, hits this problem badly enough to go looking for a solution. Not "this would be useful." Not "people probably deal with this." A specific moment, a specific frustration, described the way that stranger would describe it themselves if I asked them directly.

Every tool that actually shipped passes that test easily, because I can point to the moment. Git Dojo exists because I remember exactly what it feels like to freeze at a merge conflict with no safe way to practice the fix. Statusline Builder exists because I know precisely what it looks like when someone stares at a bare terminal prompt wanting more information without wanting to hand-write config from scratch. Those moments were never abstract to me. I could describe the stranger hitting them before I wrote a line of code.

The tool I killed never had that moment. What it had was a much weaker sentence: "this saves me a specific step I do somewhat often." True, and completely insufficient. A step that saves me time is not automatically a step that is worth someone else paying for, downloading a new tool for, or trusting a small studio with. I had been treating "useful to me" and "sellable to a stranger" as the same claim, and they are not even close to the same claim. One is a fact about my own habits. The other is a fact about a market I would need actual evidence for, not a hunch dressed up as confidence.

The frustrating part is that I already knew this test existed, in some form, before this tool. I had just never forced myself to run it early, on an idea I liked, before the liking turned into momentum. It is much easier to apply a hard test to an idea you are lukewarm about. It is much harder to apply the same test to something you already enjoy building, because by the time it is fun to work on, you have a personal stake in the answer coming back yes.

There is a version of this test that sounds almost too simple to matter, and I think that simplicity is exactly why I skipped it for as long as I did. Anyone can nod along to "make sure a real stranger wants this" as general advice. Actually stopping mid-build to write that stranger's exact sentence down, in their words, is a different act entirely, because it forces a specific claim onto paper where it can be checked instead of a comfortable feeling that gets to stay vague. A vague feeling is nearly impossible to disprove. A specific sentence about a specific person is easy to test against reality, which is precisely why it is uncomfortable to write.

The Three Signals I Ignored Too Long

Looking back at that stretch honestly, three signals were visible early and I talked myself past all of them.

The first was that I could not describe a single real conversation where someone else mentioned this exact problem. Every tool that shipped had at least one moment like that behind it, a comment somewhere, a pattern I noticed in how other builders talked about their own friction. This one had zero. I was building entirely from my own head, with no outside signal confirming the itch was shared. I noticed the silence and told myself it just meant I had spotted something nobody else had articulated yet. Sometimes that is true. This time it was a warning I chose to read as an opportunity.

The second signal was that every explanation of the tool needed a setup paragraph before it made sense. The naming test I run now exists partly because of this exact failure: if a tool cannot be explained in one plain sentence, something underneath the idea is probably not as sharp as it feels. I kept writing longer and longer explanations instead of treating that as the red flag it was. A tool that takes three sentences to justify is a tool whose actual value has not been found yet, and I was papering over that gap with better prose instead of a sharper idea.

The third signal was the quietest and the one I regret ignoring the most: I was avoiding the same self-check I run on every other product before I call it shipped. Every other tool gets walked through that check without me flinching, because I trust what it will tell me. With this one, I kept finding reasons to push the check back another session. That reluctance was information on its own. A builder who trusts an idea does not avoid testing it. I was avoiding the test because some part of me already suspected what it would say.

What Killing It Taught Me About the Tools That Did Ship

Killing the tool cost me the time already spent on it, and that stings in the moment no matter how sound the decision is. What it did not cost me was worse: a product page nobody needed, a launch announcement for something with no real audience, and the ongoing tax of maintaining, naming, and supporting a tool built on a guess instead of a signal. That second cost is the one that actually compounds. A tool that ships wrong does not just waste the time spent building it. It keeps costing attention every single day it stays live, competing for the same limited hours as the tools that do have a real audience behind them.

The real value of killing it came afterward, in how it changed what I say yes to when deciding what a fourth, fifth, or sixth tool should be. I run the stranger-moment test before I let myself get attached to anything now, not after I have already built half of it and have a sunk-cost reason to keep going. It is a much less enjoyable way to start a project. Most early excitement does not survive being forced into one honest sentence about a specific person's specific frustration. That is exactly why the test has to happen early, while walking away is still cheap.

I also got more comfortable admitting, out loud to myself, that something built well can still be the wrong thing to build. Craft and demand are two separate questions, and it is entirely possible to answer the first one perfectly while getting the second one completely wrong. I used to treat good execution as proof the idea was sound. It is not proof of anything except that I am reasonably good at building things, which was never actually in question.

The other lasting change is smaller but shows up constantly: I now write the stranger's sentence down on the very first evening an idea shows up, before I let myself open an editor for it. Some ideas survive that sentence easily, the way Git Dojo and Statusline Builder did without me forcing anything. Others stall out immediately, and I would rather watch an idea stall on day one than three sessions in, once naming, structure, and a working demo have all made it feel further along than the evidence for it actually is. A sentence costs nothing to abandon. A half-built tool costs real evenings, and evenings are the one resource a studio like this genuinely cannot get back once they are spent.

Bottom Line

The tool I killed never got a name, a product page, or a single visitor, and that is exactly the outcome I wanted once I finally asked the right question about it. It cost time I cannot get back, but it cost far less than shipping it would have, and it taught me a test I now run before an idea gets far enough to feel expensive to abandon. Every tool on raxxo.shop today survived that same question, described in one honest sentence about a stranger, not me. The one that did not survive it never got the chance to cost more than it already had.

Related reading: how I decide what to build next at a one-person studio and the feature request I say no to every time.