Why RAXXO Studios Sells Both Merch and Terminal Tools

Two Products, One Storefront

Open raxxo.shop and you land on a store that sells shirts, hoodies, prints, stickers, mousepads, and phone cases. Scroll further and the same store links out to five developer tools: Git Dojo, OhNine, Statusline Builder, Claude Blueprint, and RAXXO Studio. Most stores pick a lane. I picked two, and I still think that was the right call, though I understand why it looks strange from the outside.

The merch line exists because the RAXXO character needed somewhere to live outside a feed. A shirt, a print, a sticker on a laptop, those are small physical proof that a piece of content meant something to somebody. The tools exist because I kept hitting the same friction points while working with Claude Code every day and started fixing them for myself first, then packaging the fix for anyone else hitting the same wall.

What ties the two together isn't the product type, it's the source. Every tool grew out of a real need I had while building the content and the merch side of the studio. Statusline Builder came from wanting a better terminal setup while working on merch mockups. Git Dojo came from re-explaining rebase to myself one too many times. OhNine came from losing track of session limits mid-task. The tools are downstream of the same daily work that produces the merch designs and the content calendar.

I already wrote about why I keep shipping small tools instead of one big product (why I keep shipping small tools), and the same logic applies here. A single unified "platform" would have forced the merch and the tools into one interface, one price model, one audience. Keeping them as separate offerings under one name let each one stay simple, and let me ship both without either one waiting on the other.

It also means the store never has to pretend to be something it isn't. A lot of creator-led shops try to look like a polished consumer brand on one page and a serious software company on the next, and the seams show. Raxxo.shop doesn't hide that one person runs the whole thing. The merch pages and the tool pages both read like they were written by the same voice, because they were, and visitors seem to trust that consistency more than a slicker, more corporate split would have earned.

Why Merch Came First

The merch line predates every tool in the catalog. Before there was a Git Dojo or a Blueprint, there was a character, some visual language, and a small drop of designs printed through Printful. That came first because it was the fastest way to test whether the studio's identity meant anything to anyone beyond me. A print sells or it doesn't. A sticker gets ordered or it sits. That kind of feedback is immediate in a way that a developer tool's adoption curve never is.

Once the identity had an audience, however small, building tools stopped feeling like starting from zero. I wasn't launching an anonymous script into the void, I was extending a brand that already had a handful of people paying attention. That sequencing mattered more than I expected going in. A tool with zero context around it competes purely on utility from day one. A tool that arrives from a studio someone already recognizes gets a first look it wouldn't otherwise earn.

It also shaped the tone. Product pages for Git Dojo or Statusline Builder don't read like typical dev tool marketing copy, dense with jargon and feature grids. They read closer to how the merch pages read, direct, a little informal, focused on the one problem the thing solves. That consistency wasn't planned from a brand strategy document, it fell out naturally from one person writing both kinds of pages in the same voice on the same evenings.

Looking back, I don't think I could have built the tools first and added merch later with the same result. A print or a sticker asks almost nothing of the person buying it beyond liking the look. A developer tool asks for trust that it will actually work on someone's machine, that it will keep getting maintained, that installing it won't waste an afternoon. Earning that second kind of trust from a cold start, with no prior audience at all, is a much steeper climb than earning the first. Starting with the lower-stakes product bought time to build the reputation the higher-stakes one would eventually need.

The Tools Audience Is Not the Merch Audience

Here's the part that took longer to accept: the people buying a hoodie and the people installing Claude Blueprint are mostly not the same people. Merch buyers respond to the character and the aesthetic. Tool users respond to a specific pain point in their Claude Code workflow. Some people do cross over, someone who installs Statusline Builder and later grabs a sticker because they liked the studio enough to want a physical piece of it, but that overlap is the exception, not the baseline I plan around.

That split changes how I support each side. Merch questions are shipping timelines, sizing, print quality, the kind of thing any Printful-backed store handles. Tool questions are far more specific: a Blueprint hook not firing on a particular shell, a Git Dojo lesson not matching someone's git version, an OhNine alert not showing on a specific OS build. Answering the second kind requires actually understanding the tool at a technical level the first kind never demands.

Running both means switching contexts constantly, from "does this print run true to size" to "why is this hook silent on zsh but not bash." I used to think that context switching would be the thing that broke the setup. In practice it's manageable precisely because the two support loads land on different days more often than not. Merch questions cluster around order and shipping windows. Tool questions cluster around release days. They rarely spike at the same time, which is the only reason one person can field both without either queue backing up for long.

There's a smaller overlap worth naming too: people who ask about one line often teach me something useful about the other. A tool user pointing out a confusing install step has occasionally made me rewrite a merch product description that had the same kind of buried, unclear instruction. A merch buyer asking why a print looks different on screen versus in hand nudged me toward being more precise about screenshots on the tool pages too. Neither audience realizes it's happening, but the habit of writing clearly for one group ends up sharpening how I write for the other.

What One Person Learns Running Both

The biggest lesson is scope discipline. It would be easy to let either side sprawl, more merch categories, more tools, more variants of each. I've resisted that on both sides for the same reason: a small, well-maintained catalog beats a large, half-maintained one, whether that catalog is shirts or command-line tools. I wrote about the check I run on every tool before I call it shipped (the check I run on every tool), and that same instinct governs the merch side. I would rather have six solid print designs than twenty mediocre ones.

The second lesson is that cross-promotion has to stay light. I link the tools from the merch pages and mention the studio's story on the tool pages, but I don't force either audience to care about the other. Someone here for a terminal tool doesn't want a sales pitch for a hoodie in the middle of an install guide, and someone here for a print doesn't want to read about rebase strategies. A short, honest mention that the same studio makes both is enough. Anything heavier reads as padding, and it undercuts the thing that made either side work in the first place, which is that each one solves its own problem cleanly.

The third lesson, and the one I didn't expect, is that having two very different product lines actually steadies the studio rather than splitting its attention. A quiet week for merch orders doesn't mean a quiet week overall if a tool release lands well, and the reverse is just as true. Neither line has to carry the whole studio by itself, which takes pressure off decisions that would otherwise feel higher stakes than they need to be for an evenings-and-weekends operation.

None of this would work with a bigger team, honestly. Coordinating two product lines across multiple people would mean meetings, handoffs, someone owning merch and someone else owning tools, and the whole point would drift toward looking like two separate companies again. Staying small keeps the decision-making fast: if a tool needs a fix or a print run needs a reorder, I just do it, on whichever evening I have the time. The lack of a team is a constraint, but for holding two product lines together under one honest voice, it's turned out to be an advantage more often than a limitation.

Bottom Line

RAXXO Studios isn't a merch store that happens to sell software, and it isn't a tools company that happens to sell shirts. It's one person's studio expressing the same set of interests through two different formats, physical goods for people who like the character and the look, and free or subscription tools for people fighting the same daily friction I ran into first. The two sides don't share an audience so much as they share an origin.

Keeping them under one name instead of splitting into separate brands was the simplest choice available, and it's held up because the story stayed consistent even as the formats didn't. If you found this studio through a tool, the merch is just the same identity in a different shape. If you found it through a print or a sticker, the tools are built by the same person who designed what you're wearing. Either way, it's one studio, not two businesses wearing a shared logo.

This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)