Nobody asked for these. I started them with one engineer because our own team was losing ideas in translation.

Role: Initiated and designed. V0 built with one engineer Year: 2023 Context: Fujitsu Launchpad, internal, self-initiated Delivered: Team feedback and problem definition, concept for both tools, two-way translation design for live calls and for chat threads Outcome: Both shipped. In daily use

Tags: Product design · 0→1 · Self-initiated · Localization · JP↔EN · AI

Launchpad runs in Japanese and English at the same time. Everyone can function in both, which is exactly what hides the cost. The problem isn't failing to understand. It's the tax on attention, and the ideas that never get raised because forming them in your second language is slower than the conversation is moving.

I started this with one engineer. We collected feedback from the team on where communication actually broke, worked through the shapes it could take, and landed on two: Orion, which runs alongside a live call, and Kotobase, which sits inside a chat thread. Both translate in both directions, and neither asks anyone to change how they already work.

This was 2023. AI could translate, but not fast, cheap or reliable enough to call an API and be finished. Most of the design was deciding what the interface does when the model is slow or wrong.

The instinct is to build a translator. The actual work was deciding where translation belongs. In a call it has to stay peripheral and visible only to you, or it becomes the meeting. In a thread it has to sit inline and stay long enough to reply to, but never be stored. Those two decisions are the product, and neither of them is a translation problem.

The concept spread beyond the studio. The parent company adopted the same approach, and we extended it into the tools people were already working in, including Miro.