Fudoki

I moved to Japan and kept hitting the same small humiliation. Someone would mention they were from Saga, or that good pottery comes from Gifu, and I had no idea where either of those were. Prefectures are an important part of how Japanese people talk about their country and personal backgrounds, and I couldn't figure out what was where.

The resources that exist are English-language travel guides — where to go, what to eat. Almost nothing is built for someone who is learning the language and wants the geography in Japanese, at a level they can actually read.

Fudoki is a web app for learning the geography and regional culture of Japan's 47 prefectures. It's Japanese first, with furigana and English translations as separate toggles, for learners around JLPT N3–N2.

It has three modes:

• Explore: the map, with a panel for each prefecture covering an overview, highlights, a photo and any World Heritage sites.
• Quiz: you're given a prefecture's name and find it on an unlabeled map, with three attempts each, across all 47.
• My Japan Map: mark the prefectures you've lived in, visited or passed through, star favorites, and export a share card. It's saved only in your browser, with no account.

What I decided, and why

Japanese first, English as an opt-in. This was the product thesis. Another English guide to Japan is undifferentiated against Wikipedia and japan-guide. Japanese prefecture content with furigana, written at an N3–N2 level, was something nobody else was making. Furigana and English were provided as toggles, so a learner can dial in exactly how much help they want.

No accounts, no backend. "My Japan Map" — where you mark every prefecture you've lived in, visited, or passed through — lives entirely in the browser's localStorage. That cost me the ability to do cross-device sync and email re-engagement, but it buys instant use with zero friction, no privacy surface to defend, and a static site I can deploy by pushing to main. For a solo project with no intention to monetize, I wanted to prioritize ease-of-use and adoption over retention.

Content validity is enforced by the build. npm run validate:content runs in prebuild and fails the build unless all 47 prefectures are present, each has 3–5 highlights covering food and place and culture, overviews land in a 100–180 character window, and World Heritage labels appear only where a site is genuinely inscribed.

Prioritizing clean data

I shipped the analytics layer before the first distribution.

A launch is a one-shot event. Untracked traffic is unmeasurable forever — you don't get to go back and instrument it. So I hunkered down to define a robust instrumentation plan before launch, including a rule to log atomic events, define metrics downstream. Never fire a user_activated event. Fire prefecture_viewed and define activation as a query over it later, once you know where the curve actually inflects. Hardcoding the threshold in the client destroys your ability to ever redefine it.

Then I wrote down four predictions about the funnel and committed to them publicly in the repo, before there was any data, so that being wrong would be informative rather than embarrassing.

What happened

Distributed to three channels on 2026-07-22, including a Japanese learning discord, the r/LearnJapanese subreddit, and my personal LinkedIn. 426 unique visitors over the first week.

Prediction	My guess	Actual
Landings that open ≥1 prefecture	55–70%	67.8%	✅
Sessions that find the quiz	20–30%	23.0%	✅
Quiz starts that reach question 47	<25%	27.6%	❌
7-day return rate	<10%	9.6%	✅

Three of four were inside my prediction range. The miss changed what I built next. I had initially suspected a 47-question quiz was too long and may result in substantial dropoff. However, the quiz completion rate exceeded my expectations. So instead of shortening the quiz, I went and looked at where people actually left.

44% of everyone who answered a first question was gone by question 5. Almost everyone who reached question 10 finished the quiz.

The opening was the problem, not the length. Quiz questions were a randomly drawn from all 47 prefectures, so a new player could open on Saga, Fukui and Tokushima (lesser known prefectures) back-to-back and reasonably conclude the thing was impossible.

I shipped an eased opening: the first five questions are drawn from a pool of the ten well-known prefectures new users could likely place. All 47 are still asked exactly once, an easy question is still worth the same points, and the maximum score is unchanged — so scores stay comparable across the change.

Two other learnings from my launch:

• Community beat volume, 40 to 1. A dedicated learner Discord returned 257 visitors. The r/LearnJapanese weekly promo thread returned 6. (Caveat: I posted that one ~12 hours late, so it kills that placement, not the subreddit.)
• First-touch referrer was $direct for 398 of 426 people. Discord and mobile app clients strip referrers entirely. Without UTM tags on every outbound link, my launch would have been 93% unattributable and the channel comparison impossible.

What I'd say about all this honestly

Predicting your own funnel within a few points is mildly encouraging about product intuition, and that's all it is. At n=426 every one of those numbers carries a confidence interval several points wide, and the sample is essentially one Discord server. They describe that audience, not the product.

The part I'd actually defend is the process: instrument before you launch, write down what you expect before you look, and let the number you got wrong pick your next piece of work.