English and Turkish from day one: what bilingual launches cost and what they return

Every app we ship speaks English and Turkish from its first version. It is the team's reality more than a strategy, but it has turned into one of the better decisions we made, and the reasons are not the obvious ones.

Retrofitting is the expensive path

An app built in one language has that language hard-coded in a hundred places nobody remembers. Adding a second one later means finding them all. Building with two from the start means the structure for any language exists from the first commit, and the third language, when it comes, is a translation job rather than an engineering one.

The second language finds your mistakes

Turkish words are often longer than English ones, and sentences are built differently. The first bilingual build exposes every layout that only fit English and every string assembled from fragments that make no sense in another grammar. Fixing those makes the app more robust for every language, including English.

Two store pages, two sets of data

Two localized store pages means two keyword sets, two search term reports and two conversion rates from day one. We learn things about how people describe the product in one market that improve the page in the other.

A second market keeps you honest

Prices that work in one storefront do not in the other. Trial behaviour differs. What counts as a good screenshot headline differs. Having two real markets from launch means the product's assumptions are tested against two realities rather than one, which is a cheap way to find out which assumptions were just habits.

What it costs

Every string written twice, every screenshot made twice, every review answered in the reviewer's language, every release note in two versions. A real cost, carried by the person who owns the app. It is smaller than it sounds once the habit exists, and much smaller than the cost of doing it later.