Two things held up after I scanned 92 developer tools for how ready their front door is for a Japanese buyer. One thing I wanted to be true didn't, and I'm not going to fake it.
First: readiness isn't a slope, it's a cliff. A tool either ships a real Japanese site or it ships nothing. Of the 52 tools I added this round, 36 scored a flat zero and 16 had a genuine localized surface. Almost nothing sat in between.
Second, and this is the one I didn't expect. The companies that did localize, the mature ones with a Japanese marketing site and a Tokyo office, still skip the two signals that actually gate a purchase. Datadog, Snowflake, MongoDB, Okta, Twilio, Atlassian, Elastic, Databricks. Every one of them has a polished Japanese site. None of them has a 特商法 page. None of them prices in yen.
The thing I couldn't get was a clean "more readiness means more Japan revenue" number. More on why below, and why I'd rather say "I can't measure this" than dress up a correlation that falls apart when you push on it.
This is a follow-up. The first pass covered 40 tools and nearly all of them scored zero, which is useless for learning anything because there's no variance to look at. So this round I deliberately stacked in the incumbents to see what the top of the range looks like. Total is now 92 distinct tools, scanned the same way.
The cliff
The score distribution has basically two piles and an empty middle.
| where it lands | how many (of 52 new) |
|---|---|
| scored exactly 0 | 36 |
| genuine localized JP surface | 16 |
| somewhere in between | almost none |
And every single one of the 16 with a real Japanese surface is a late-stage or public company. Nothing early-stage cleared the bar. The early and mid-stage tools (Bun, Replit, Groq, Mistral, Qdrant, CockroachDB, and most of the rest) returned <html lang="en"> with zero Japanese characters and no /ja route worth the name.
I'm fairly sure the cliff is real. I'm less sure why the middle is empty. My best guess is that partial localization has almost no payoff, so a team either commits a full Japan motion or doesn't bother, and you rarely see the half-built version in public.
One honesty note that matters: the jump from ~3 localized tools in the first 40 to 16 here is not a market shift. It's selection. I added the incumbents on purpose to find the ceiling. If you read this as "the market is getting more localized over time," that's me stacking the deck, not a trend. Don't take that number as movement.
Even the localized incumbents stop one step short
This is the part worth sitting with.
The mature companies already did the expensive work. Staffed Japan, shipped a full Japanese site. These aren't /ja routes that 200-OK into an English shell. Stripe's /ja-jp renders around 36,000 Japanese characters. Atlassian's /ja around 20,000. Snowflake's /ja around 5,700. Real pages a Japanese buyer can actually read.
And then they stop. Across all 52 tools this round:
-
特商法page in the homepage HTML: 0 of 52 - real default-JPY pricing: ~0 (Stripe lists JPY in its currency data, the only borderline case)
So the companies that spent the most on Japan still leave the cheap legal and billing trust layer on the floor.
I don't read this as negligence, and I don't think it's worth dunking on anyone for it. It looks structural. Localization is a marketing project with a clear owner and a clear KPI. The 特商法 page and JPY handling live in a seam between legal, finance, and growth, and that seam has no obvious owner. So it falls through, even at companies sophisticated enough to localize 36,000 characters of marketing copy. The same crack catches the beginner and the incumbent.
Quick reminder of why a Japanese buyer reacts to the 特商法 gap specifically, since it's the one signal that's both cheap and high-impact. Japanese buyers, including individual developers and procurement teams, are trained to scroll to the footer and look for the 特定商取引法に基づく表記 page before they pay. When it's missing, the read isn't "they broke a law." It's "this vendor isn't set up to sell to us," and they quietly leave. You never see that in a support ticket. It's silent.
The correlation I couldn't honestly draw
Going in, the question I actually wanted to answer was: does higher readiness predict more Japan traction. It would've been the headline. It doesn't hold up, for two reasons, and both are worth stating plainly.
One. There's no cheap public proxy for real traction. JP revenue share, JP customer count, JP monthly actives: none of it is public. The only thing I could pull from a page was whether a careers or company page names Japan or Tokyo. That measures "this company has a Japan org," not "this company makes money in Japan."
Two. Even on that weak proxy, readiness and the Japan-org flag move together almost perfectly. Of the 16 with a localized surface, 15 also name Japan in careers. Of the 36 zeros, basically none do. That looks like a strong correlation right up until you notice the causality runs the wrong way for the thesis. A company makes an APAC bet, hires a Japan team, and then localizes the site. Readiness is a lagging symptom of a go-to-market decision, not a leading cause of revenue. Bolting hreflang and a 特商法 page onto an early-stage tool would not manufacture the revenue Datadog has.
So I'm dropping the correlation claim. It's confounded and I can't observe the outcome side, and a number you can't defend is worse than no number. What survives is the boring, checkable stuff: the cliff, and the incumbent gap. Both are just things you can see in the HTML.
One thing the scanner got wrong (and I'd warn you about)
While I'm being honest about numbers. My first run over-reported JPY readiness, and I want to flag the bug because if you build your own scan, it'll bite you too.
The currency check matched the bare substring jpy. Which means it happily flagged base64 asset hashes, a CSS class (css-1lxjpys on MongoDB), and build-hash fragments on a handful of others. Seven false positives out of eight things it flagged. I caught it re-checking the passes by hand, which felt wrong for that many "wins," subtracted the bogus ones, and tightened the match to require an actual currency context. Every JPY number above already has those seven removed. Lesson, if you want it: jpy as a loose substring is not a currency signal, it's a footgun.
How I measured it
Each value is a deterministic function of fetched public HTML. curl, Accept-Language: en-US, follow redirects. Five signals: discoverability (hreflang / lang / .jp / ja-path), Japanese content over 80 characters, JPY, 特商法, language switcher. On top of that I probed /ja, /jp, /japan for a real localized surface, and read careers or company pages as the weak Japan-org proxy. No value is fabricated. Anything I couldn't verify is marked as such. Scan date 2026-06-29.
A 200 from a /ja path is not localization, by the way. The rendered Japanese character count is. That distinction is doing a lot of work in the 16-vs-36 split.
If you maintain one of these
If your tool is in the set and you want the exact per-signal evidence string for its score, I keep that per tool and I'm happy to hand it over. If something shipped since 2026-06-29 and a number here is now wrong, tell me and I'll correct it. I'd rather be corrected than confidently stale.
The readiness raw isn't public yet. If you want to see the format I publish data in, two other public sets are up in the same spirit: sibling-leftover-dataset (structural sibling bugs mined from merged PRs, CC-BY-4.0) and cjk-agent-fixtures (runnable CJK / IME regression fixtures, MIT). Both are checkable line by line, which is the only kind of claim worth making here.
Top comments (0)