Case Study: 4 Years Delivering a Japanese MEO SaaS for 90,000 Stores — the Operating System That Kept Specs From Degrading
- Problem: A large-scale MEO SaaS (used by 90,000+ Japanese stores) with specs dense in Japanese SEO/Google Maps API terminology — one misunderstood term by the Vietnamese dev team meant a full sprint delay.
- Solution: A 4-layer operating system — a shared Japanese-Vietnamese tech glossary, two-stage spec checks, 100% PR review, 24-hour escalation — which I ran directly for 4 years as Delivery Manager.
- Result: Almost zero features rebuilt due to spec misunderstanding, zero release delays (client-confirmed), 15x growth in 3 years carried by a 31-person team, and the contract renewed 4 consecutive years.
For 4 years I directly ran delivery for a Japanese MEO SaaS used by over 90,000 stores, as Delivery Manager and BrSE on the Vietnamese side. The outcome: almost zero features rebuilt due to spec misunderstanding, 15x growth in scale over 3 years, and a contract renewed 4 years running. This article opens up the 4-layer operating system behind those numbers.
TL;DR (Executive Summary)
- Problem: Specs dense with Japanese SEO/Google Maps API terminology — one misreading by the Vietnamese team meant a full sprint delay.
- Solution: 4 layers — a shared JP–VN glossary / two-stage spec checks / 100% PR review / 24-hour escalation — operated for 4 years.
- Result: Near-zero redo from spec misunderstanding, zero release delays (client-confirmed), a 31-person team carrying 15x growth, 4 consecutive renewals.
Project background: where the difficulty actually was
The project is a Japanese MEO (Map Engine Optimization) platform — a large SaaS that analyzes and optimizes store visibility on Google Maps. The difficulty wasn't the technology; it was the nature of the specs:
- Specs packed with Japanese SEO/Google Maps API domain terms ("rank measurement", "indoor view", "citation"…)
- Large data scale — a misread aggregation logic only surfaces after release
- Sprint-based development — one misunderstanding drags the entire sprint
In other words, ideal conditions for the "Japanese quality evaporating as tacit knowledge" problem to erupt.
The 4-layer operating system — what got mechanized
Layer 1: A shared Japanese–Vietnamese tech glossary
The first thing I built wasn't code or process — it was a glossary. Each Japanese domain term mapped to its technical definition, Vietnamese translation, and a real data example, referenced by both the Japanese side and the dev team. Is "ranking" search ranking or listing ranking? That class of interpretation drift was eliminated by a shared document, not by any individual's language skill.
Layer 2: Two-stage spec checks
Specs get checked twice. Before development starts — the BrSE validates technically, flags ambiguities and contradictions, and queries the Japanese side. After completion — the deliverable is checked against the spec again before the demo. Discovering a misunderstanding after building costs tens of times more than asking before building, so a no-shame-in-asking culture was guaranteed by rule, not encouragement.
Layer 3: 100% PR review
Every pull request was reviewed before merge to catch logic errors early. Recurring comments were folded into a criteria sheet — shifting from person-dependent review to standards-based review.
Layer 4: 24-hour escalation
Any problem or risk had to be shared with the Japanese side within 24 hours of discovery — daily meetings and end-of-day reports in Japanese were the channel. The Vietnamese cultural default of "solve it first, report it after" was overwritten by the explicit rule that early reporting is rewarded.
Results — 4 years in numbers
| Metric | Result |
|---|---|
| Features rebuilt due to spec misunderstanding | Near zero (minor drift fixed via continuous kaizen) |
| Release delays | Zero — client's words: "Spec transmission errors disappeared, and release delays went to zero" |
| Business growth | Carried 15x scale growth in 3 years |
| Usage scale | 90,000+ paying stores |
| Team | 31-person Vietnamese team managed directly |
| Contract | Renewed 4 consecutive years |
Note what these numbers have in common: none came from "building faster" — all came from structurally eliminating misunderstanding. Offshore success isn't decided by coding speed but by how little gets rebuilt.
Reusable lessons from this case
- Invest in a glossary before investing in language skills — a shared dictionary is the cheapest, highest-leverage defense against misunderstanding.
- Check twice: "before" and "after" — questions before building are cheap; discoveries after building are expensive.
- Anchor escalation to time — "report if it's serious" doesn't work; only a mechanical rule like "within 24 hours" crosses cultural gaps.
- Measure success by how rare redo is — high velocity with frequent rebuilds is still a failing delivery.
Frequently asked questions
Does this operating system work for small projects?
Yes — the smaller the project, the cheaper the adoption. The glossary starts as one spreadsheet; the two-stage check starts as two checklists. What matters isn't tooling but the design philosophy: misunderstandings are blocked by mechanism, not by individual carefulness.
As a client evaluating vendors, what should I ask based on this case?
Ask candidate vendors: "Show me the actual artifacts of your spec-misunderstanding defenses." Whether a real glossary or review criteria sheet appears is exactly the "real quality processes" test from the 5-axis offshore vendor evaluation.
If your Japan–Vietnam project suffers from "constant rebuilds and slipping releases", simply mapping which of the 4 layers is missing usually reveals where to start. If you'd like to discuss your specific situation, feel free to share your case. I typically respond to cases that fit my expertise and current availability.