Stop Translating, Start Designing: What Building for Two Languages Taught Me About Actually Understanding Your Product

I made a mistake six months ago. We launched the Urdu version of a project management tool I'd been working on in Islamabad by hiring a translator, dropping their work into our codebase, and calling it a day. Three weeks later, a user in Karachi reported that our core task creation flow didn't make sense in Urdu. Not the words—the entire mental model was wrong. The sequence of questions, the terminology, the way we framed "priorities"—all of it assumed an English-speaking Western workflow. I realized then that I'd been thinking about localization completely backwards.

The article I read about building a bilingual daily planner crystallized something I've been wrestling with: localization is not translation. Translation is what Google does. Localization is what designers do. And it's way harder.

The Vagueness Problem

Here's what stuck with me: English is forgiving. Too forgiving. You can slap "Get things done" on a productivity app and people nod along. Everyone projects their own meaning onto those four words. Traditional Chinese, apparently, won't let you get away with that. The language structure demands specificity. You have to explain what things, whose things, by when.

This is actually brilliant product thinking disguised as a language problem.

When I went back and looked at our task creation form—originally built in English—it was full of these vague affordances. "Set priority." Okay, but priority relative to what? For whom? In what timeframe? Users in Urdu markets asked the same questions explicitly, which forced us to redesign the entire interaction. Turns out, that redesign made the English version better too.

I think in English first, which means I think in abstractions. When I have to render those abstractions in another language with different grammatical rules, I hit a wall that forces actual clarity. That wall is a feature.

Hiring for Understanding, Not Translation Skills

The biggest lesson here is organizational. I could have hired the best Urdu translator on the planet and still shipped garbage because translation is mechanical. What you actually need is someone who lives in the market you're designing for.

Our breakthrough came when we brought on a developer from Lahore who understood how teams in Pakistan actually work—the cultural expectations around deadlines, the way "clarity" is communicated in professional settings, what a task really means in daily practice. She didn't translate our English copy. She rewrote the entire value proposition because the way we framed productivity was foreign to the market.

This changes hiring completely. If you're building for a new market, you're not looking for a translator. You're looking for a product person who happens to speak that language.

The Quality Filter Effect

Here's the counterintuitive bit: building in two languages simultaneously made our English version leaner and better. We couldn't ship features we couldn't explain in both languages. Bloat died.

There's this tendency in English software development to add complexity just because we can articulate it. "Let's add a recurring task feature with custom intervals and..." and suddenly we've built NASA's scheduling system when what users needed was "every Monday, 9 AM." Building in Urdu forced us to ask: can we explain this feature's value in the simplest possible way? If not, it's probably not valuable.

What I'd Do Differently Now

Start bilingual from day one if you know you're building for multiple markets. Don't retrofit this later. It's exponentially more painful to refactor a product's conceptual foundation at scale than to bake it in during design.

Second, don't think of localization as extra work tacked onto your timeline. Think of it as quality control. The constraints of designing for another language will catch fuzzy thinking in your primary market that you'd otherwise ship with.

Third—and this is the hard one—hire for cultural clarity early. Before you have product-market fit. Before you're confident about your market. Because that hiring decision will reshape your product in ways that make it actually work for both markets instead of just being readable in both languages.

The Question I'm Sitting With

I keep wondering: how many product decisions are bad not because they're poorly executed, but because they were made in a single language and single cultural context? How many "missing features" that users request are actually pointing to a broken mental model we baked in at the start?

If you're building something that'll be used internationally, what's stopping you from starting bilingual today?

Source: This post was inspired by "I Built a Bilingual Daily Planner — Here's What I Learned About AI and Language" by Dev.to. Read the original article