DEV Community

greymoth
greymoth

Posted on • Originally published at japan-readiness.glovrex.com

The Japan-readiness Standard

There's a gap most software has and few teams can see: the distance between "works globally" and "sellable in Japan." This is an attempt to name that gap and measure it the same way every time.

I call it Japan-readiness. Here's the rubric I score against.

The rubric leans on the part most checklists skip: the legal and commercial layer. Plenty of tools will tell you your Japanese typography is off. Fewer will tell you that without a 特定商取引法 page and a qualified-invoice number, you can't compliantly sell to a Japanese customer at all. Typography is taste; those two are law. So the rubric treats the legal layer as the part that actually blocks a sale, and weights it that way.

The six dimensions

1. Locale & hreflang. Does the site tell a Japanese browser there's a Japanese version? An hreflang="ja" alternate and a real lang signal. This is the cheapest thing to get right and the most commonly missing.

2. 特定商取引法 (Specified Commercial Transactions Act). To sell to Japanese consumers, the law requires a disclosure page: seller, address, contact, pricing, returns. No page, no compliant sale. A scanner can see whether the page exists. Whether it's complete is a human and legal call.

3. Invoice / T-number (インボイス). Since October 2023, Japan's qualified-invoice system means a registered business needs a 13-digit registration number to issue invoices buyers can deduct. Absent number, friction for every B2B customer.

4. JP payments. Yen pricing, and the methods Japanese buyers actually use: bank transfer, convenience-store payment, invoice-based billing. Dollars-only is a wall, not a rounding error.

5. CJK typesetting. When Japanese text does appear, does it render correctly? Line breaking, half-width and full-width handling, font fallback. Broken CJK reads as "this wasn't made for me."

6. IME input. Do the input fields survive a Japanese input method? Composition events, validation that doesn't reject kana mid-conversion. Quietly broken forms lose users who never tell you why.

The grades

Each dimension carries a weight. The total maps to a grade.

  • S / A — set up to sell in Japan, with real localization.
  • B / C — partial. Some signals, real gaps.
  • D / F — not set up to sell in Japan. Usually not a failure, just a market the team hasn't reached yet.

An F is a map, not an insult. Most global tools score low here for the same reason: from outside Japan, these requirements are structurally invisible.

What this is, and what it isn't

This is a rubric I'm proposing and scoring publicly, not an official certification. It detects the presence of signals. It does not certify legal completeness, and it never will from the outside. Where it can only see "exists or not," it says so.

It's a starting standard. If you sell software in Japan and think a weight is wrong or a dimension is missing, tell me and I'll revise it in the open. A standard earns its name by being used and corrected, not by being declared.

I'm keeping the scores public and the index growing. The point is a shared, repeatable way to answer one question: how far is this product from being sellable in Japan.


Free scanner that runs this rubric on any URL: https://japan-readiness.glovrex.com. Faceless dev in Tokyo, mapping the Japan-shaped holes in global software.

Top comments (0)