Before I build any RAXXO tool, I spend real time using the existing options in that category, not just skimming their landing pages
I am looking for the specific moment each competitor's tool disappoints someone, not a list of missing features
The best ideas usually come from a small, repeated annoyance, not a big obvious gap
A teardown that finds nothing worth fixing is a good reason to not build the tool at all
Why I Never Start With a Blank Page
Every RAXXO tool starts the same way, and it is not with a blank page or a fresh idea sketched on its own. It starts with me opening every existing tool I can find in that category and actually using them, the way a real person would, for a real task, start to finish. Not reading the marketing copy. Not skimming a features list. Using the thing until I hit the point where it stops working the way I need it to.
This runs against the instinct to protect a new idea from outside influence, the fear that looking too closely at what already exists will just make you build a copy of it. I understand the instinct, but in practice the opposite risk is bigger. Building without looking first means you are guessing at what is actually missing from a category, and guesses are expensive once you have spent real time building around one. A teardown replaces the guess with something closer to evidence.
Git Dojo came out of exactly this kind of session. I sat down expecting to find a gap in git reference material, assuming the category needed a better cheat sheet. What I actually found, after working through several existing tools, was that almost none of them taught git inside the terminal itself. They taught it in a browser tab, next to the terminal, asking you to context-switch constantly between where you were learning and where you were actually typing commands. That gap was not visible from a features list. It only showed up once I was the one trying to learn something and kept losing my place switching windows.
I keep a running note during every session like this, not a formal document, just a plain list of the exact moment something went wrong and what I was trying to do when it happened. Writing it down in the moment matters more than it sounds like it should. If I wait until the end of the session to summarize what I noticed, I default to remembering the tidy, general impression instead of the specific friction, and the specific friction is the only part that is actually useful later.
What I Am Actually Looking For
A teardown is not a competitive feature audit. I am not making a spreadsheet of what every tool in a category has and does not have, checking boxes against a list. Feature parity tells you almost nothing useful, because two tools can have an identical feature list and completely different experiences using them. What I am actually hunting for is a specific moment: the point where a real task using an existing tool stops feeling smooth and starts feeling like work.
That moment is usually small. It is rarely a missing feature. It is more often a tool that has the right feature but makes you fight it to use, or a tool that answers the question you asked instead of the question you actually meant. Statusline Builder came from a version of this. Every terminal customization tool I tried before building it technically let you configure a statusline, and every one of them buried that configuration behind a text file and a syntax I had to look up every single time I touched it. The feature existed everywhere. The friction around using the feature was the actual gap.
Finding that moment takes patience, because it usually does not show up on the first pass. The first ten minutes with any tool tend to go fine, since most products are built to demo well. The real signal shows up later, on the third or fourth task, once the tool has to handle something slightly outside its cleanest use case. I try to push past the polished first impression on purpose, specifically looking for the task that makes the tool show its seams, because that seam is usually the actual opportunity.
I also try to use each tool for something a little unusual, not just the obvious first task the product clearly expects. A tool built for one clean use case will almost always handle that use case well, since that is exactly what its own team tested against. Pushing it slightly sideways, toward a real but less common task, tends to surface the assumptions baked into the product faster than any amount of time spent on the intended path. Those assumptions, once visible, are often the clearest map of where the category has settled for good enough instead of actually good.
The Annoyance Test, Not the Ambition Test
Once I find a candidate gap, I run it through a specific filter before deciding it is worth building around: is this a small, repeated annoyance, or a big, dramatic missing feature. The instinct is to chase the dramatic one, because it sounds like a bigger opportunity. In practice, the small repeated annoyance is almost always the better signal.
A big missing feature usually means the category has decided, collectively, that the feature is not worth building, often for reasons that are not obvious from the outside. Maybe it is technically hard for a reason I have not run into yet. Maybe it does not actually matter to enough people to justify the cost of building it. A small annoyance is different. It is evidence that people are already using tools in this category regularly, hitting the same friction over and over, and just accepting it because nothing better exists yet. That is a far more reliable signal than a gap nobody else has bothered to fill.
OhNine came from an annoyance this small: existing usage trackers for AI tools made you open an app or a dashboard to check a number that mattered constantly throughout the day. Not a missing feature. A wrong place for a piece of information you need often enough that opening a separate window every time is genuinely annoying. Putting it in a menu bar was not ambitious. It was closing a small, repeated gap that a teardown made obvious once I noticed how often I was opening that dashboard just to check one number.
The tell that separates the two, in practice, is how the annoyance shows up during actual use versus how it shows up when you are just thinking about the category in the abstract. A dramatic missing feature usually surfaces when I am imagining what a tool could theoretically do, sketching an ambitious version in my head before I have even opened a competitor. A small repeated annoyance only shows up mid-task, in the exact moment something takes longer or feels clunkier than it should. I have learned to trust the second kind far more, because it is grounded in something that actually happened rather than something I imagined could happen.
When the Teardown Says Do Not Build It
The most useful outcome of a teardown is sometimes deciding not to build the thing at all, and I do not treat that as wasted time. If I spend real hours in a category and come away without a clear moment where existing tools disappoint someone, that is a legitimate finding, not a failure to find one. It means the category is either already served well, or the gap I originally suspected was smaller than I thought before I actually tested it against reality.
This has killed more RAXXO tool ideas before they started than any other single check I run, more than any specification review after the fact. It is a much cheaper way to lose an idea than building it first and discovering the same thing after the fact, once real hours are already spent on it. A teardown that finds nothing is doing exactly the job it is supposed to do, closer in spirit to the raxxo tool I killed before it ever shipped, just moved earlier, before any building happens instead of partway through it.
The habit only works if I am honest about the outcome, which is harder than it sounds once an idea has started to feel exciting. It is tempting to keep looking until I find some gap to justify building the thing I already wanted to build, stretching a minor inconvenience into a bigger opportunity than it actually is. I try to catch myself doing that specifically, because a teardown run backwards from a decision I have already made is not research anymore. It is a search for permission, and it defeats the entire point of running the check before I am attached to the outcome.
One thing that helps is setting a rough stopping point before I start, a number of tools I plan to actually sit with, rather than deciding in the middle of the session whether I have looked at enough. Without that boundary, it is too easy to keep going exactly until the moment a gap appears that flatters the idea I already had, then stop right there and call it evidence. Deciding the shape of the search ahead of time, before I know what it will find, keeps the result closer to honest.
Bottom Line
A teardown is not about copying what already exists or avoiding it out of fear of looking too similar. It is about finding the specific, repeated moment where real tools in a category disappoint real people doing real tasks, then deciding honestly whether that moment is worth building around. The dramatic missing feature is usually a trap. The small, boring annoyance that keeps showing up is usually the real opportunity, because it means people are already living with the friction and just accepting it. Sometimes the honest result is deciding not to build anything at all, and that outcome is worth exactly as much as finding a real gap, because it saves the much larger cost of finding out the same thing after I have already committed to building it. Every RAXXO tool, from Git Dojo onward, started with this same session before a single line of the actual product got built.
Top comments (0)