Most foreign dev-tools don't lose Japan because Japanese developers dislike them. They lose it earlier and quieter than that — in a dozen small places where the product technically works but never quite lands. The demand is already there; it just leaks out before it ever shows up in your analytics.
I keep noticing the same gaps, in the same order, across very different products. None of them are hard to fix. The expensive part is not knowing they're there.
I've now scored 13 products against these signals and published the gap maps publicly. The index is at jp-ready (live index) — each product page links to the specific GitHub issue or live URL I verified against.
This is the pattern behind those scores.
The tell: users are translating your product for you
Here's the signal almost everyone misses. Long before a Japanese user files a "please support 日本語" ticket, a smaller group just… does it themselves.
- Penpot has a community member who showed up on the issue tracker and said, plainly, "I would like to participate in translating the project into Japanese." (penpot/penpot#5128)
- NocoDB ships a community-contributed Japanese README — "NocoDB ✨ オープンソースのAirtableの代替案 ✨" — sitting right in the repo. (japanese.md)
- GoHighLevel's public idea board has a Japanese user arguing there is "a significant and growing latent demand in the Japanese market," with another user volunteering to help.
When strangers volunteer to translate your product on their own time, that's not a feature request. That's demand that already exists, partially captured, leaking through the cracks.
1. The funnel is English-only, top to bottom
The product might have a ja locale buried in settings. The path to it almost never does. Landing page, pricing, docs, onboarding emails, error states — all English. A Japanese buyer evaluating you has to read your entire sales funnel in a second language before they even reach the part you localized.
Cal.com example: the product has 4,635 Japanese locale keys (391 KB of translation). cal.com/ja returns a 404. Real investment in the product, no Japanese marketing path.
Two cheap things move the needle here disproportionately:
- A visible language switcher (not a locale auto-guessed from the browser and then hidden)
-
hreflangalternates so Google.co.jp and Yahoo! Japan actually surface your Japanese pages
Neither requires touching the product. Both are usually missing.
2. No 特商法 (Tokushoho) page — and Japanese buyers look for it
If you sell to consumers or small businesses in Japan, there's an expected legal disclosure page under the Act on Specified Commercial Transactions (特定商取引法 / Tokushoho): who you are, what you sell, at what price, refund terms, contact. Stripe documents this requirement for merchants operating in Japan.
Foreign products almost never have one. For a careful Japanese buyer, its absence reads as "this company isn't really set up to sell here" — a trust gap, before price is even discussed.
It's the single most universal gap I found across the 13 products.
3. USD-only pricing
A USD price tag does two things to a Japanese buyer: it makes the cost fuzzy (converted at whatever rate, on whatever card), and it quietly signals "you're not really our market."
There's also a tax wrinkle: Japan applies 10% Japanese Consumption Tax (JCT) to many cross-border digital sales. Showing a clean JPY price — and ideally offering payment methods Japanese buyers default to (credit card, konbini, bank transfer) — removes friction that pure-USD checkouts leave on the table.
4. Invisible for the searches that matter
Japanese buyers rarely search your brand name first. They search the category in Japanese — "プロジェクト管理 ツール", "Airtable 代替", "オープンソース ○○" — and increasingly ask an AI assistant the same thing in Japanese. If you have no Japanese-language page, no category framing in Japanese, and no hreflang, you simply aren't in those answer sets.
This is the gap that compounds: it's not one lost user, it's every user who searched in Japanese and never saw you.
5. IME and CJK bugs that English-speaking devs never hit
Japanese input goes through an IME (Input Method Editor): you type romaji, the IME composes candidates, and you press Enter to confirm a conversion. If your app treats that Enter as a submit event, you've broken typing itself.
Real examples, all from public trackers:
- NocoDB — pressing Enter to confirm a Japanese IME conversion also gets interpreted as "create a new record." Typing a cell value becomes a minefield. (nocodb/nocodb#10394)
- Chatwoot — an IME bug in AI reply fields (#13765) breaks Japanese composition in the support interface.
- Twenty CRM — a Unicode bug rendered Japanese text as raw escape sequences in field display (#13665).
A monolingual English team can ship for years without ever triggering any of these. A Japanese user hits them in the first five minutes — and most won't file an issue, they'll just leave.
The index
I've now mapped 13 products publicly at jp-ready (live index). Every gap links to the GitHub issue or live URL I verified against. Scores range from 16–28 out of 100.
That range isn't meant as a ranking — it's a reflection of how consistently these signals get missed. The products themselves are good; the gaps are just not visible from outside the market.
If you want to check your own product, the five dimensions above are the full methodology. Nothing proprietary — you can run the same checks manually in under 30 minutes.
Want a free map for your product? Email hello@glovrex.com with your URL.
Every example above links to a real, public source. Status of individual issues changes over time — open the links for current state. If anything here or in the index is wrong, the opt-out contact is on every page.
Top comments (0)