One inbox handles support for five RAXXO tools, and for a long stretch I let it dictate my whole day instead of the other way around
A three-bucket triage (fix now, answer now, write it down for later) cut my average reply time without adding a single tool or a single hire
The rule that changed the most was refusing to answer from memory, because a rushed answer from memory is how the same question comes back twice
The inbox now feeds the product roadmap directly, and half of what ships in a given release started as three people asking the same thing in the same week
One Inbox, Five Products, No Team
Every RAXXO tool ships with the same promise on the product page: if something breaks or confuses you, a real person answers. Nobody told me, when I wrote that line the first time, what it would feel like to be the only real person behind five different products at once. Git Dojo questions arrive next to Statusline Builder questions next to a note about Claude Blueprint's install step, all in the same thread view, all expecting the same speed of reply regardless of which tool they are actually about.
For a while I treated the inbox as background noise, something to clear between the actual work of building. That was backward, and it took a run of slow replies to notice. The inbox is not separate from the work. It is the fastest, least filtered signal I get about whether a tool actually does what I think it does once it leaves my hands. A bug report is not an interruption to development, it is development, just delivered in the wrong tense (something already shipped, not something in progress) and often in a tone that assumes I already know what went wrong.
The hard part was never answering any single message. It was the shape of five products worth of questions arriving with no pattern to when they land. A quiet Tuesday can turn into eleven messages by evening, three of them about the same Git Dojo command, two of them unrelated bugs in two different tools, and one that is really a feature idea wearing a bug report's clothes. Without a team, there is no queue to hand any of it off to. There is just the order I open them in, and for a long time that order was "whichever one I saw first," which is close to the worst possible system.
I run every RAXXO tool myself before anyone else does, and I assumed that habit alone would keep the inbox quiet. It helps, it catches the obvious breaks before a customer ever finds them, but it cannot catch the thing dogfooding never will: the exact word someone uses when they are confused, at 11pm, on a device I was not testing on. That gap is what the inbox actually measures, and once I started reading it that way instead of as a chore, the whole relationship to it changed.
The Three-Bucket Rule That Keeps It From Swallowing My Day
The fix was not a tool. It was a rule I now apply before I let myself reply to anything: every message goes into exactly one of three buckets before I write a single word back.
Bucket one is fix now. This is a real bug, confirmed, reproducible, and small enough that fixing it takes less time than writing a good explanation of why it happened. If a message lands here, I fix the thing first and reply with what changed, not with a promise about what will change later. A shipped fix is a better reply than any sentence I could write.
Bucket two is answer now. The tool works as intended, the person just could not find the answer, and the answer already exists somewhere, in a doc, in a setting, in an onboarding step they skipped. These get a direct reply, fast, with the exact step, not a link to "check the docs" that makes someone go hunting again.
Bucket three is write it down for later. This is the bucket that used to trip me up, because it feels like the least urgent one and it is actually the most important. A well-reasoned feature request or a small, non-blocking friction point does not need an answer in the next ten minutes. It needs to be recorded honestly, with enough context that I can act on it during actual product time, not squeezed into a reply written half-distracted between two other threads.
Sorting first, before writing anything, sounds like it should slow replies down. It did the opposite. Deciding the bucket takes seconds. Writing a good reply without deciding the bucket first used to take minutes, because I was solving the triage problem and the writing problem in the same sentence, and doing both badly.
What I Refuse to Answer From Memory
The rule that changed the most was smaller than the bucket system and easy to miss from the outside: I do not answer technical questions from memory anymore, even when I am confident I remember correctly.
This sounds like a small discipline. It was not, in practice, because memory is exactly where a solo support inbox quietly breaks. Five products, each with its own settings, its own edge cases, its own version history, and one person trying to hold the current behavior of all five in his head at once. Confidence and correctness are not the same thing, and for a stretch I was answering fast and being wrong often enough that the same question came back a second time, worse, from someone who had already tried my first answer and watched it not work.
Now the rule is simple. If a reply depends on a specific, checkable detail, current behavior, a exact setting name, a version where something changed, I check it in the actual product before I send the reply, every time, even when I am sure. It costs thirty extra seconds per message on average. It has nearly eliminated the second message, the one where someone writes back with "that didn't work" and I have to start over having already spent their patience once.
The other thing I stopped doing was over-promising in the moment just to close a thread quickly. A quick "I'll look into that" that never gets followed up on is worse for trust than a slower, honest "that's a real issue, here's what I can tell you today and here's what I still need to check." People do not expect one person to have instant answers to everything. They do expect that when I say I will follow up, I actually do, and that rule is the one I protect hardest, because breaking it once costs more trust than a slow reply ever does.
How the Inbox Feeds Back Into the Product
The biggest shift was realizing the inbox is not a cost center sitting next to the product, it is a direct input into what the product becomes. The first messages after any launch tell me exactly where an explanation was missing, and that signal does not stop after week one. It just gets quieter and more specific, which makes it more useful, not less.
When the same question shows up from three different people in the same week, that is not three separate support tickets. That is one product gap wearing three different disguises, and the fix is never "answer faster." The fix is closing the gap so the question stops arriving. Some of those gaps turned into rewritten onboarding steps. Some turned into an error message getting rebuilt from scratch, since a confusing error message generates its own support volume all by itself, and fixing the message once removes a whole category of future replies I would otherwise have to write by hand, over and over, forever.
I keep a running list, separate from the inbox itself, of every question that took more than one attempt to answer well. That list is not a support log, it is closer to a product backlog written entirely in the customer's own words instead of mine, and it reads more honestly than any internal notes I could write on my own, because nobody phrases a real point of confusion the way I would phrase it if I were guessing at what confuses people.
Not every recurring question turns into a shipped change. Some are genuinely one-off, a setup unique to that person's machine or workflow, and forcing a product change to solve a single case would make the tool worse for everyone else. Telling those apart, the pattern from the outlier, is its own skill, and it is the one part of running this inbox alone that I do not think a bigger team would do meaningfully better. A team adds people between the question and the decision. Alone, the person answering the message is the same person who decides whether it changes the product, and that shortens the loop in a way that is genuinely hard to replicate with more hands on it.
That list also tells me when a tool has quietly stabilized. A product that used to generate three or four write-it-down entries a week and now generates none is not a product I stopped paying attention to, it is one where the gaps got closed. Watching that count drop to zero is a better sign of a finished feature than any internal checklist, because it comes from actual use, not from my own guess at whether something was done.
Bottom Line
The support inbox for five RAXXO tools used to feel like the tax I paid for shipping things solo, the part of the job that ate hours without ever showing up in a changelog. It stopped feeling that way once I stopped treating speed as the only thing that mattered and started treating the inbox as the most honest feedback channel I have. The three-bucket sort keeps the day from being swallowed by whichever message happened to land first. Refusing to answer from memory keeps a fast reply from turning into a second, angrier one. And letting repeated questions become product changes, not just faster canned answers, is the part that actually compounds. A solo inbox will never scale the way a support team does, and I have made peace with that. What it can do, better than a team often can, is stay close enough to the actual confusion that the product keeps getting sharper because of it, one honest reply at a time.
Top comments (0)