A RAXXO tool does not get a name until it can describe its own function in one plain sentence
Every name has to survive being typed in a terminal, said out loud, and read as a URL slug with nothing lost
Git Dojo, OhNine, and Statusline Builder all failed their first proposed name before they shipped
The naming test now runs before a single line of code, not after the product is already built
The Naming Test I Run Before Anything Else
I used to name things last. Build the tool first, figure out what to call it once it worked, treat the name as decoration on top of the real work. That order produced some genuinely bad names, and worse, it meant I sometimes shaped a product around a clever name I had already gotten attached to instead of the other way around. Somewhere around the third RAXXO tool I flipped the order completely, and I have not gone back since.
The test is simple to state and harder to pass than it sounds: can I describe what the tool does in one plain sentence, using words that are already in the name or close to it. Statusline Builder builds a statusline. Git Dojo is a place you practice git. OhNine tracks a usage window that resets like a clock. If the name and the one-sentence description do not rhyme with each other, the name is wrong, no matter how good it sounds on its own.
This sounds obvious written down, but it rules out almost every instinct I have as a designer. My first instinct is always toward something evocative, a little abstract, the kind of name that sounds good in a pitch deck and means nothing to a stranger seeing it cold. Evocative names work when a brand already has reach and can afford to spend months teaching people what the name means. A one-person studio does not get that runway. Someone lands on a product page having never heard of RAXXO Studios, and the name is doing sales work before a single sentence of copy loads. If the name does not carry meaning on its own, that visitor is relying entirely on the page around it to explain what they are looking at, and pages get skimmed.
So the test happens before anything else. Before a design file, before a line of Liquid, before I let myself get attached to an idea. I write the one sentence first, then try to find a name inside that sentence, not the other way around. It slows down the fun part of starting a new tool, and I have made peace with that trade, because a name I have to explain every time is a tax I would otherwise pay forever.
Where the Names Actually Came From
Git Dojo passed the test almost by accident. I was describing the tool to myself as "a dojo for git," a place to practice the real commands until they stopped feeling foreign, and I realized I had already said the name out loud without meaning to. Dojo carries the right meaning on its own: a place you go to practice a skill under low stakes until it becomes reflex. Pairing it with git left nothing to explain. Nobody has ever asked me what Git Dojo does based on the name alone.
OhNine took longer, because the honest one-sentence description, a menu bar tracker for a usage window, does not contain an obvious noun to build a name around. I went through several literal options first, all of them accurate and all of them forgettable. The one that stuck came from the reset time itself, a specific hour that matters to anyone watching a usage window closely. It is a smaller leap than Git Dojo's name, but it still points at something real instead of being invented from nothing, and that was the bar I held it to.
Statusline Builder barely needed a naming pass at all, and that turned out to be a lesson of its own. Some tools are literal enough that fighting the literal name is just ego. I tried a handful of more stylized alternatives before admitting none of them communicated faster than just saying what the tool builds. A free tool especially cannot afford friction between the name and the function, because a visitor deciding whether to click has less patience for a free product than a paid one, not more.
Claude Blueprint is the clearest example of a name doing double duty on purpose. A blueprint is a plan you follow to build something specific, and that is exactly what the product hands someone, a structured plan instead of a pile of loose notes. I considered names that leaned harder into the packaging angle, the fact that a lot of scattered material got compressed into one install, but packaging language tends to describe the process behind a product rather than what a user actually gets from it. Blueprint won because it describes the outcome, not the effort that produced it, and outcome language is almost always the stronger choice once I notice I am choosing between the two.
The Names I Killed Before They Shipped
Every one of those final names has at least one predecessor that did not survive the test. I do not keep a formal graveyard of dead names, but the pattern in the ones I killed is consistent enough to describe. Almost all of them failed for the same reason: they sounded good read silently and fell apart the moment I said them out loud or tried to type them into a terminal prompt as part of a demo.
A name that trips on its own syllables when spoken is a name that will get mispronounced in a video, mistyped in search, and shortened by users into something I never chose. I learned to say every candidate name out loud, more than once, in a normal speaking voice, before it got anywhere near a domain or a page title. Several strong-looking names on paper did not survive that read-aloud pass, usually because they leaned on a pun or a double meaning that only works in text.
The other repeat failure mode was reaching for a word that already carries baggage from somewhere else. A name can be memorable and still be the wrong choice if half of what a stranger associates with the word has nothing to do with what the tool does. I would rather have a plainer name with zero prior associations than a punchier one fighting an unrelated meaning for space in someone's head. That rule alone eliminated more strong candidates than any other single filter I use.
A third failure mode showed up less often but hurt more when it did: a name that only made sense once I explained the joke behind it. I am a sucker for a clever internal reference, the kind of name that rewards someone who already knows the backstory. Every single one of those names died in testing, because a stranger has no backstory to draw on and no patience to go looking for one. A name that needs a footnote to land is not ready, no matter how much I like the footnote. The test forced me to separate what amused me from what actually communicated, and those two things overlap far less often than I expect going in.
What a Name Has to Survive Once It Ships
A name that passes the test still has to survive contact with the actual system it lives inside, and that is where the technical side of naming shows up. Every RAXXO section file follows a strict pattern, section-[page]-[name].liquid, and every custom class in it carries an rx- prefix so it never collides with anything the Fabric theme already defines. A product name that does not translate cleanly into that pattern creates friction for me on every single file I touch for that product afterward, which is a cost most naming advice never accounts for because most naming advice is not written by the person who also has to type the filename a thousand times.
The same test applies to the page slug. /pages/git-dojo and /pages/ohnine read exactly like the product name because I insisted on it during naming, not after. A slug that has to abbreviate or reorder the name to fit a URL is a small tax paid on every single link I ever write to that page, including every internal link inside a Lab article like this one. I would rather spend an extra day on the name up front than pay that tax on every future article, every share link, and every terminal command someone runs to visit the page directly.
I also test how a name looks sitting next to the others in a list, because RAXXO products are increasingly discovered together rather than one at a time. A name that only works in isolation, next to nothing else, is a weaker name than one that still reads clearly in a row of five. That is less about branding theory and more about a very specific, testable moment: someone scrolling a page that lists every RAXXO tool at once, deciding in about two seconds which one to click.
Bottom Line
Naming moved from the last step to the first step once I noticed how much time a bad name cost me later, in filenames, in URLs, in explaining a clever idea to someone who just wanted to know what the tool does. The test is not complicated: say it out loud, type it in a terminal, read it as a one-sentence description, and see if anything gets lost along the way. Git Dojo, OhNine, and Statusline Builder all passed that test only after an earlier attempt failed it.
I do not think there is a shortcut around doing this test early. A name chosen after the product exists is a name shaped by attachment to work already done, and attachment is exactly the thing that makes a bad name hard to kill. Doing it first, before there is anything to be attached to, is the only version of the process that has actually worked for me more than once.
Top comments (0)