I reply to every public review a RAXXO tool gets, five stars or one, inside the same day I see it
A one-star review taught me more about a confusing install step than three rounds of internal testing ever did
My reply template is two sentences for a good review and five for a rough one, never longer, never defensive
Reviews now shape the product page copy before they shape anything else, because customers describe the product better than I do
The Review That Almost Made Me Defensive
The first bad review I ever got was for Statusline Builder, and it was short: the export button didn't match what the demo video showed. My first instinct was to explain myself. I had a whole paragraph ready about how the UI changed between the video and the release, how the export button moved for good reasons, how the person had probably missed the update. None of that paragraph was for the customer. It was for me.
I sat on the reply for an hour, which is longer than I usually take, and I deleted the explanation. What I sent instead was three sentences: I confirmed the export button had moved, I said exactly where it lived now, and I thanked them for flagging it because the demo video needed a re-record. That was it. No defense of the decision, no history lesson about why the UI changed. Just the fix and the thanks.
That review is still the one I think about when a new one comes in, because it set the rule before I knew I needed a rule. A public review is not a debate. It is one person telling me, in public, where the product and their expectation stopped matching. My job in the reply is to close that gap as fast and as plainly as I can, not to win an argument nobody asked me to have. The customer who left that review never came back to read my reply, probably. But everyone who reads the review after them does, and what they see in the reply matters more than what they see in the star rating.
I run five products alone, and every one of them gets reviews now, not just the merch. Git Dojo gets reviews about specific exercises. OhNine gets reviews about how it behaves with different Claude plans. Claude Blueprint gets reviews about the install step, always the install step. Different products, same rule: reply the same day, reply short, reply like the reviewer is standing in front of me instead of typing into a box I might never open. Most of them do get opened, and fast, because a review with no reply for two weeks tells the next reader the studio went quiet, and quiet reads as gone.
Two Sentences For Five Stars, Five For One Star
I keep the reply length tied to the problem, not the star rating, but in practice that maps almost exactly onto stars. A five-star review usually says the product did what it promised, and there is nothing to fix, so the reply is two sentences: thanks, and a specific detail from their review so it does not read like a template. If someone says Git Dojo's rebase exercise finally made rebasing click for them, I say that exact thing back, not a generic thank you. Generic thanks reads like a bot wrote it, and a bot reply under a real review makes the whole page feel less human, even the good reviews above and below it.
A one-star or two-star review gets five sentences, capped. Sentence one names the problem back to them so they know I read it, not skimmed it. Sentence two says what is true right now, plainly, even if what's true is "this is a known limitation and I have not fixed it yet." Sentence three gives the workaround if one exists. Sentence four says what happens next, a fix date if I have one, an honest "I am looking into it" if I don't. Sentence five is the thanks, always last, never first, because leading with thanks before addressing the problem reads as deflection.
I write these replies myself, every time, because a customer can tell when a reply was drafted by someone who has never used the product. Five products is a lot to hold in my head at once, but the reviews are short enough that reading the product's own docs page for thirty seconds before replying beats guessing. I link the docs page in my own head before I answer a technical review, not in the reply itself, because the reply should read like a person, not a support ticket.
What Reviews Taught Me About The Product Page
The install-step complaint on Claude Blueprint's reviews showed up three separate times before I did anything about the product page, and that is on me, not on the customers who each independently hit the same wall. Three people describing the same confusion in three different ways told me something my own testing hadn't: I knew the install step so well that I could not see it as a stranger would. That is the real value of a public review over an internal test. I cannot un-know how my own product works. A first-time user can't fake not knowing either.
After the third install-step review, I rewrote that section of the product page from scratch, using the exact words customers had used in their reviews, not the words I would have chosen. Where I had written "configure your environment variables," a reviewer had written "I couldn't figure out where to paste the key," and that second phrase is what went into the page. Reviews are customers doing free usability testing and then also telling me, in their own language, what the fix should sound like.
This connects to a rule I already hold hard on feature requests: I say no to most one-off asks, but a review pattern is different from a single request. One person wanting a feature is a preference. Three people independently confused by the same page is a defect in how I explained the product, and defects in explanation get fixed before anything else on the list, ahead of new features, ahead of most bugs that don't affect data or money. A confusing product page costs every future visitor, not just the one who complained.
I check reviews across all five products in one pass, usually once a day alongside the rest of the support inbox triage, because a review is really just support feedback that happens to be public. Treating it as a separate, lower-priority queue was a mistake I made early on, when I let reviews sit for days because they felt less urgent than a direct email. They are not less urgent. They are more visible.
The One Rule I Never Break: Never Argue In Public
I have wanted to argue in a reply exactly twice, both times over a review I thought was unfair, one that blamed the product for something a different tool had done. Both times I wrote the corrective reply and both times I deleted it before posting. What I posted instead was shorter: I confirmed what the product does and does not do, without a single word implying the reviewer was wrong to be confused. Being technically right in a public reply and looking petty in a public reply happen at the same time, and only one of those outcomes matters to the next reader.
The rule is simple because it has to survive moments when I am tired, defensive, or just wrong about how annoyed I have a right to be: no reply gets posted the minute I write it. I write it, I close the tab, and if I still think it is the right reply an hour later, I post it. That single hour has caught almost every reply I would have regretted, the same way sitting on that first Statusline Builder reply did. A cooling-off rule sounds like a small thing for a one-person studio to enforce on itself, but it is the only editor I have.
The other half of the rule is that a reply never mentions another customer, another review, or a comparison to a competing tool, even when a reviewer brings one up first. The reply stays about the one conversation in front of it. Reviews are permanent and searchable, and a reply that drags in a third party turns a two-line disagreement into a screenshot somebody keeps. I would rather lose the point than win it in a way that outlives the argument.
None of this means every review gets a soft answer. If a review states something factually wrong about a product, like claiming a feature doesn't exist when it does, I correct it plainly, with a link to where the feature actually lives. Politeness is not the same as letting a wrong claim stand uncorrected for every future reader. The difference is tone, not honesty.
I have also learned to leave a review alone when the honest reply is nothing at all. A handful of reviews over the years have been pure venting, no specific complaint attached to them, nothing a reply could actually fix. Answering those with a forced apology would have implied the studio did something wrong when it mostly hadn't, and answering with a defense would have broken the no-arguing rule from the other direction. Silence is a valid reply exactly there, and only there. Every review with a specific, nameable problem still gets one, inside the day, no exceptions.
Bottom Line
Replying to every review, good or bad, inside the same day, was not a customer-service decision as much as a product-design one. Reviews are the cheapest, fastest, most honest usability testing a one-person studio gets, and ignoring the bad ones to protect my own mood would have cost every product a slower feedback loop than I can afford to run alone. The two-sentence and five-sentence templates keep me consistent across five very different products without turning every reply into a research project, and the one-hour delay on anything that feels personal has saved me from more than one reply I would have regretted seeing archived forever under a product page. The habit costs a few minutes a day. What it buys is a product page that describes the product the way customers actually experience it, not the way I imagine they do.
Top comments (0)