The One-Line Pitch I Rewrite Last for Every RAXXO Tool

Why I Write the Pitch Last, Not First

Most advice about building a product tells you to write the pitch first. Nail the one sentence, then build toward it. I understand the theory. A clear pitch up front is supposed to keep the build honest, a north star you check against every decision. I tried it that way for the first couple of RAXXO tools and kept running into the same problem: the sentence I wrote on day one was a guess, and the tool I actually shipped rarely matched the guess.

Git Dojo is the clearest example. I sat down expecting to build something close to a git cheat sheet with nicer formatting. Three weeks into actually building it, the interesting part turned out to be the terminal-first teaching flow, not the reference material. If I had locked in a pitch on day one, it would have described the wrong product by the time I shipped. Writing the pitch early does not protect the build. It just means you are marketing something that does not exist yet.

So now the pitch comes last, after the tool works, after I have used it enough times to know what it is actually good at. This is not laziness about the sentence. It is the opposite. A pitch written before the product exists is describing an intention. A pitch written after is describing a fact you can point to. Every RAXXO product page, every social caption, every line in a launch post traces back to that one late sentence, so getting it right matters more than getting it early.

The tradeoff is that I spend the whole build without a settled pitch to lean on, which means every internal decision has to be judged against the underlying problem instead of a marketing line. That turns out to be the better discipline anyway. A pitch is a compressed answer. You cannot compress an answer you do not have yet, and pretending you do just locks in the wrong compression.

It also means I have to resist a specific temptation partway through every build: writing the pitch early just to feel like the project has direction. A settled sentence feels like progress even when it is fiction. I have learned to read that feeling correctly now. Wanting a pitch before the tool is finished is usually a sign I am unsure what the tool actually does yet, and the fix for that is more building and more using, not a better sentence written from uncertainty.

The Three-Second Test

Once a tool works, I run every pitch draft through the same test. Someone scrolling past a product page, a social post, or a search result gives it about three seconds before they decide whether to keep reading or move on. The sentence has to work completely alone in that window, with no surrounding context, no follow-up sentence to clarify what the first one almost said.

Most first drafts fail this test in the same way: they need a second sentence to actually land. "Statusline Builder helps you customize your terminal." That is not wrong, but it needs another sentence explaining what a statusline even is and why customizing one matters, and by the time that second sentence shows up, the three seconds are gone. A pitch that needs a follow-up sentence to make sense is not a pitch. It is the first half of one.

The rewrite has to do the whole job alone. "Statusline Builder turns your terminal prompt into a live dashboard, no config file required." That version does not need anything after it. It tells you what changes (your prompt becomes a dashboard), what problem it removes (the config file), and it does both in one breath. Getting there is rarely about writing something clever. It is about cutting the sentence down until only the load-bearing words are left, then checking whether it still stands up completely alone.

I read every draft out loud before I trust it, which sounds like a small habit but catches a surprising amount. A sentence that reads fine on a screen often reveals its own clutter the moment you have to say it in one breath. If I run out of breath before the sentence lands its point, it is still too long, no matter how good it looked as text.

There is a second version of the test I run right after: showing the sentence to someone who has never seen the tool and watching their face for the half second before they either nod or ask a question. A question means the sentence left a gap it should have closed itself. A nod, even a small one, means the sentence did the whole job alone. I trust that reaction more than my own judgment at that point, because I have spent too many hours with the product to read the sentence the way a stranger would.

Feature Language vs Outcome Language

The single most common mistake in an early pitch draft is describing a feature instead of an outcome. Feature language explains what the tool does mechanically. Outcome language explains what changes for the person reading it. Both can be technically accurate about the same product, and only one of them makes anyone care.

An early draft for RAXXO Studio read something like "RAXXO Studio analyzes uploaded video frames and generates platform-specific captions." That sentence is correct. It is also completely uninteresting to someone deciding whether to click, because nobody wakes up wanting frame analysis. The outcome version reads closer to "one video in, three platform-ready captions out, no more rewriting the same post three times." Same product. The second sentence tells you why you would want it before it tells you how it works.

I catch myself defaulting to feature language constantly, because feature language is what I actually spent weeks thinking about while building. The mechanism is vivid in my head, so it is the first thing that comes out when I try to describe the product. The outcome is what the person on the other side of the screen actually experiences, and it takes a deliberate second pass to translate from one to the other.

A useful check: if the sentence would only make sense to someone who already understands the underlying mechanism, it is still feature language. "Terminal-native git tutorials" only means something to someone who already knows what terminal-native implies. "Learn git in the same terminal you already work in, not a browser tab pretending to be one" does the same job for someone who has never thought about the distinction before. The second version does not assume the reader already agrees the feature matters. It shows them why it would.

What Using the Tool First Catches That Nothing Else Does

The real value of writing the pitch last is not about better sentence craft. It is about accuracy. Once a tool exists and I have actually used it the way a real customer would, for real tasks, over real sessions, I know exactly what it does well and exactly where it strains. A pitch written before that point is guessing at both.

I found this out the hard way on an early draft for OhNine. The tool tracks usage limits from a menu bar, and my first pitch draft said it gave you "complete visibility" into your usage. It sounded fine until I had actually lived with the tool for a week and noticed the specific moment it was genuinely useful, the quiet warning before you hit a wall, versus the moment it was just a number sitting in a menu bar that I had already stopped looking at. "Complete visibility" overclaimed a feeling the tool did not actually deliver in daily use. The rewrite narrowed to what it does reliably: the warning before the wall, not a promise of constant awareness I was not actually experiencing myself.

That is the pattern every time. Using the finished product surfaces the honest edges of what it does, and the edges are exactly what a pitch written from intentions alone cannot see. It is easy to write an aspirational sentence about a tool that does not exist yet. It is much harder to write an inflated sentence about a tool you have personally used for two weeks, because you already know where the claim would not hold up, and writing it anyway starts to feel dishonest in a way that is easy to notice once you are the one who has to stand behind it.

This is also why I keep the product page and the pitch as separate jobs done at different moments. The product page gets written earlier, closer to when the shape of the tool is settling. The one-line pitch waits until after real use, because it carries more weight per word and has less room to hide an inaccurate claim.

Bottom Line

Writing the pitch last feels backwards until you have shipped a few tools and watched an early guess turn out to describe the wrong product. A one-line pitch is not a marketing formality. It is the compressed, honest answer to what a tool actually does, and you cannot compress an answer you have not lived with yet. The three-second test keeps it self-contained. The feature-versus-outcome check keeps it about the reader instead of the mechanism. But the real discipline is refusing to write the sentence until the tool exists and I have used it enough to know exactly where it earns its claims and where it does not. Every RAXXO tool gets the same treatment, whether it is Git Dojo or something named an hour before launch. The pitch is the last sentence I write, and it stays the one I trust most, because by the time I write it, I have already found out the hard way whether it is true.