Every RAXXO tool ships its interface, docs, and support replies in English first, even though the studio runs out of Germany
One language across five tools means one voice to maintain instead of five drifting translations
German-only requests get a real reply, just in English, and nobody has asked twice
Adding a second language is a distribution decision, not a hospitality one, and the numbers have to earn it first
The Decision Nobody Warned Me About
I did not expect language to be a decision at all. I thought it was a default: write the product in whatever language the code comments are already in, ship it, move on. Then the first support email came in written in German, from someone who had bought a RAXXO tool on a UK-registered domain with EUR pricing and a UI that never once switched languages. That email is the moment the decision became real. I had to answer it, in English, and decide whether that was a one-off or a policy.
I made it a policy. Every RAXXO tool, whether it is Git Dojo, OhNine, Blueprint, Statusline Builder, or whatever ships next, runs in English first. The product copy, the onboarding screens, the docs, the support replies, all of it. Not because English is more correct or because I think it is more professional. Because a solo studio has exactly one of me, and one of me cannot maintain five products in two languages without one of those languages quietly rotting.
The policy also had to survive a test I run on every studio-wide rule before I trust it: would I still choose it on a bad week, not just a calm one. A language rule only chosen when there is spare time to spend on it is not really a rule, it is a hobby that disappears the moment a launch gets tight. English first survives the bad week because it removes work instead of adding it. There is no second draft to write when a feature ships at midnight before a deadline, no second string file to update when a button's copy changes for the third time in an afternoon. The rule earns its place by making the busy weeks easier, not by making the calm weeks feel more thorough.
I have seen that rot happen to other small studios. A German version gets shipped at launch, out of what feels like hospitality, and then six weeks later a feature ships in English only because there was no time to translate it. Now the product has two experiences: a complete one and a stale one, and the stale one is the one that makes a local customer feel like an afterthought instead of a priority. A single, well maintained language beats two half maintained ones. I decided early which failure mode I was willing to risk, and it was not the silent-drift one.
This connects to a decision I made about pricing for the same reason. I cover the reasoning in why RAXXO prices everything in EUR: pick one standard, apply it everywhere, and let the discipline of "everywhere" do the work that a special case never does. Language got the same treatment. One standard, no exceptions, no per-market variants that need separate upkeep.
What "English First" Actually Means Day to Day
English first does not mean English only in some absolute, robotic sense. It means English is the language every new sentence gets written in, and every other language is handled as a reply, not a rewrite of the product.
When a support request comes in written in German, French, or anything else, I read it, understand it, and reply in English. I have done this dozens of times. Nobody has ever written back confused, and nobody has asked me to switch to their language for the rest of the thread. What people actually want, in my experience, is a real answer from a real person quickly, not a translated interface. The interface being in English does not stop someone from buying, using, or writing in to a RAXXO tool in whatever language they think in. It just means the product itself, the thing I have to keep correct forever, only exists in one place.
This is also why the account layer stays out of the way. I wrote about the related decision in why every RAXXO tool works without an account first: the fewer required steps between someone landing on a page and getting value, the fewer places a language mismatch can even become friction. A one-field checkout, a single clear button, a short line of copy, these things translate across a language barrier better than a paragraph ever does. Simple English reads faster than complicated English, and it reads faster than machine-translated anything.
Docs get the same rule. Every RAXXO tool has one docs page, in English, kept current with the product because there is only one version to keep current. If I split that into two languages, I would either update both every time or quietly stop updating one, and I already know which one loses.
Error messages get extra scrutiny under this rule, more than marketing copy ever does. A marketing sentence that reads a little stiff in a second language is forgivable. An error message that reads stiff or unclear in any language is the moment someone gives up and closes the tab. So I write every error string in plain, short English first, the same instinct behind the piece I wrote on the error message I rewrite until a stranger understands it, and I trust that a genuinely clear sentence survives being read by someone thinking in a different language better than a clever one does. Clarity turns out to be the real translation layer, more than the language the words happen to be written in.
Why I Have Not Localized, Even From Germany
The obvious question: the studio runs from Germany, so why not ship German as a first-class language, at least for the store itself? I have thought about this more than the decision probably deserves, and the answer keeps coming back to the same place: localization is a distribution decision, not a courtesy, and I have not seen the distribution case yet.
A second language is not a translation file, it is a second product surface. Every new feature needs a second version written or reviewed. Every UI change needs a second string checked for length, because German runs long and breaks layouts that fit English comfortably. Every support macro needs a second draft. Every piece of marketing copy needs a second pass that actually sounds like a person and not a translation tool. That is real, recurring work, multiplied by five products, forever, not a one-time cost that pays off after launch.
I would take that cost on the day the numbers say a meaningful share of buyers are choosing not to buy because the product is in English. I watch for that signal the same way I watch the metrics I check every week for anything else. So far it has not shown up. People from non-English markets buy RAXXO tools regularly, EUR pricing already tells them the store understands their region, and the support replies in their own language handle the rest. English-only for the product, warm and responsive for the human on the other end of an email, has been enough.
There is a Berlin-specific version of this same tension I ran into outside the studio entirely, which I wrote about in the Berlin tech scene in 2026. Berlin's creative and tech scene runs on English as a working language more often than not, even among people who did not grow up speaking it. That was not the reason I made the call for RAXXO, but it told me the instinct was not unusual. English as the working language of a product does not read as foreign here. It reads as normal.
The Line I Would Change It At
I do not treat this as a permanent rule, and I want to be honest about where I would reconsider it. If one specific RAXXO tool found a real, sustained audience in a single non-English market, one language, one country, one clear signal, I would consider localizing that tool specifically rather than the whole studio at once. That is a very different decision from "translate everything because it feels more welcoming." It is a distribution bet backed by an actual pattern, made for one product at a time, with a clear owner of the ongoing cost.
What I would not do is localize preemptively, on the theory that it might help. Preemptive localization is exactly the kind of work that looks generous on day one and becomes a liability by month three, once the first language falls behind the second and both start looking half finished. I would rather ship one language completely than two languages partially, and that preference has held up every time I have tested it against a real request.
I also weigh what localizing one tool would cost the other four, because nothing at a one-person studio happens in isolation. A week spent building and maintaining a second language for one product is a week not spent on the shared design system, the support macros, or the next tool waiting to ship. That opportunity cost is easy to miss when a localization request lands in an inbox and feels urgent in the moment. It only becomes visible a month later, when something else slipped because the time went somewhere else. So the bar for a second language is not just "would this help," it is "would this help more than anything else I could do with the same hours," and English first keeps winning that comparison.
Bottom Line
Shipping every RAXXO tool in English first was not a statement about which language matters more. It was a capacity decision from a studio with exactly one person keeping every product current. One language means one voice, one docs page, one support macro library, one thing to get right instead of several things slowly drifting apart. German, French, and every other language still get a real answer, just written by hand instead of built into the interface, and that has covered every request so far. The day a specific product shows a specific, sustained reason to localize, I will do it for that product alone, deliberately, not as a blanket policy applied because it felt polite at launch. Until then, one language, kept honest, beats two languages kept half true.
Top comments (0)