I write the product page for a RAXXO tool while it is still half built, not after launch
A page that is honest about what the tool does not do yet catches scope problems weeks before a single support ticket would
Three sections force the same discipline every time: the problem, the screenshot, and the one line that says who this is not for
The page usually changes the build more than the build changes the page
Why the Page Comes Before the Finish Line
Most product pages get written last. The tool ships, someone opens a blank document, and they try to describe something that already exists in its final form. I do the opposite. I write the product page for a RAXXO tool while it is still half working, screens still missing, edge cases still unhandled. It feels backward the first time you try it, and it is uncomfortable on purpose.
The discomfort is the point. When I try to write a clear sentence about what a tool does and I cannot, that is not a writing problem. That is the tool telling me it does not know what it is yet. The docs page I write before I touch the code catches the same kind of gap from the technical side, before a single line ships. The product page catches it from the buyer's side, before a single line of marketing copy gets typed for real.
Here is what actually happens. I open a blank page and try to write one sentence: what does this tool do, for whom, and why would someone reach for it instead of the five other things they could use. If that sentence comes out clean on the first try, the tool's scope is probably right. If it takes four tries and still reads like two products stitched together, the tool is trying to be two things. Better to find that out with a paragraph than with a codebase.
I learned this the slow way, building a tool that eventually needed a whole second product page split off from the first, because I had written the original page late, after the build already had momentum, and momentum makes you defend decisions instead of question them. Writing early means I have no momentum yet. Nothing to defend. Just a description that either holds together or does not.
There is a second reason I write it early, and it has nothing to do with catching mistakes. A blank product page is a good place to remember why I wanted to build the thing in the first place. Deep into a build, the reasons blur into a list of remaining tasks, and it becomes easy to keep shipping features because they are on the list rather than because they still serve the original problem. A page written on day one is a record of that original intent, and rereading it later works like a compass more than a checklist.
The Three Sections That Never Change
Every RAXXO product page I draft early follows the same three-part shape, regardless of what the tool actually does. First, the problem, written as something a real person is doing right now, not as a category. Not "project management for developers" but "you have four terminal tabs open and you cannot remember which one is running the build." Specific enough that I can picture the exact moment someone would reach for this.
Second, a description of the one screen or one output that matters most, written before that screen fully exists. This is the hardest part, because I am describing something I am still building, and it is tempting to describe the version in my head rather than the version I can actually ship on the timeline I have. So I write it, then I go check whether the current build can support what I just wrote. Usually it cannot, not yet, and that gap becomes the next few sessions of work instead of a surprise at the end.
Third, one line about who this is not for. This is the section most product pages skip, and it is the one that does the most work. A statusline tool is not for someone who wants a full dashboard. A terminal git teacher is not for someone who wants a GUI. Writing that line early keeps me from quietly widening the tool to please an audience it was never built for, which is exactly how a focused tool turns into a mediocre general one. Why I keep shipping small tools instead of one big product is the direct result of taking that third section seriously every single time.
I write these three sections in plain language first, no formatting, no headers, just the same sentences I would say out loud to someone asking what I am building. Polish comes later. The plain version is where the honesty lives, and polish tends to hide the parts that were never quite true.
None of the three sections is allowed to borrow language from the other two. The problem section cannot mention the product by name. The screen section cannot restate the problem. The exclusion line cannot soften into a feature list disguised as a boundary. Keeping them separate forces each one to justify itself on its own, and a section that cannot stand alone is usually a section propping up a weak idea with the sentence next to it.
What the Page Catches That the Build Cannot
A build tells you whether code runs. It does not tell you whether the thing you built solves the problem you started with. That gap is invisible from inside the editor and obvious on a product page, because a page has to commit to a claim in a full sentence, and code never has to.
I have cut features mid build because the product page made the value indefensible. If I cannot write an honest sentence about why a feature matters to the person in that first section, I stop building it, because a feature nobody can explain in one sentence usually cannot be explained to a buyer either. That check has saved me from shipping things that would have sat there unused, quietly making a tool feel more complicated than it needed to be for everyone who did use the parts that mattered.
The page also catches naming problems early, because a screen described honestly on a page tends to expose when a button, a setting, or a whole feature is named for what it does internally rather than what a person trying to use it would call it. How I name every RAXXO tool before I build it covers the tool-level version of this same habit. The product page runs it one level down, on every individual claim inside the tool, not just the tool's name.
Screenshots matter here too, even rough ones. I try to capture a real screen early, not a mockup, because a mockup shows the version of the tool I wish existed and a real screenshot shows the version that actually does. When the real screenshot looks worse than the sentence next to it promises, that mismatch is worth fixing before launch, not after someone points it out in a review. It is a small, cheap way to catch overpromising before it becomes a pattern across a whole product line.
I also read the draft page out loud at least once, which sounds like a small habit but catches a specific failure mode: sentences that read fine on screen but sound evasive when spoken. A claim that is technically true but leaves out an important limitation almost always trips on the tongue before it trips on the page. If I stumble reading a sentence out loud, I go back and find the part I was quietly hedging on, and I either fix the tool so the sentence becomes fully true or I rewrite the sentence to say what is actually there.
When the Page Changes the Build
The honest answer is that the page changes the build more often than the build changes the page, and that ratio is exactly why I do this early instead of at the end. A build in progress is soft. Screens can move, a setting can get renamed, a feature that does not fit can get pulled without anyone noticing it was ever planned. A build that is already announced and screenshotted everywhere is much harder to walk back, and walking it back after launch means admitting a mistake in public instead of quietly fixing one in private.
I keep the early draft of the product page next to the tool's working notes the whole time I am building, and I reread it every few sessions, not to polish the writing but to check whether the tool still matches what the page claims. Drift shows up fast this way. A setting I meant to keep simple grows three extra options because a build decision made sense in isolation but nobody checked it against the promise on the page. Catching that drift early is cheaper every time than catching it after the check I run before I call anything shipped, which is really the last gate, not the first one. The check I run on every tool before I call it shipped happens close to launch. The product page happens long before that, and it is meant to make the final check smaller, not replace it.
By the time a tool is actually finished, the product page I wrote at the start rarely survives word for word. Screenshots get replaced with real ones, rough phrasing gets tightened, a feature description gets cut because the feature itself changed shape. But the shape of the page, the problem, the one screen that matters, the line about who it is not for, almost always survives intact. That shape was the actual product decision. Everything after it was execution.
I keep the early drafts around after launch too, instead of deleting them once the final page replaces them. They are the clearest record I have of how a tool's scope actually moved from a blank page to a shipped product, and rereading an old draft next to the finished tool tells me more about my own build habits than any single retrospective note ever could.
Bottom Line
Writing the product page early is not a marketing trick. It is a forcing function that makes me commit to a plain sentence about what a tool does before the tool exists to hide behind. Code can run without ever answering that question. A page cannot. That difference is why the page goes first now, every time, for every RAXXO tool, no exceptions.
It costs almost nothing to write three honest paragraphs before a build gets serious, and it has saved me from shipping features nobody could explain, names nobody would recognize, and scope that quietly drifted past what the tool was ever meant to be. The page does not have to be good writing at this stage. It has to be true writing. Good comes later, once the build has something worth describing well.
Top comments (0)