Why we built Solvory in 16 languages from day one
Most fintech ships in English first and translates later. Here's why we did the opposite — and why it changes who actually uses the product.
The default playbook for a US-headquartered SaaS is: ship in English, prove product-market fit, translate later when growth slows.
We did the opposite. Solvory shipped in 16 languages from launch — English, العربية, Français, Español, Türkçe, Deutsch, 中文 (simplified and traditional), 日本語, 한국어, हिन्दी, Português (Brazilian and Portuguese), Русский, Bahasa Indonesia, Spanish (US Latino dialect). Full translations, including categories, payment methods, recurrence patterns, and notification copy. RTL layouts, not just RTL text.
Here's why.
Personal debt is a global problem, not an American one
The premise of Solvory is that money owed between people is rarely about the money — it's about clarity and dignity. That premise is true everywhere. It's more true in cultures with extended-family financial obligations, multi-currency households, and informal networks of trust. India, the Levant, the Philippines, Brazil — these are places where personal-debt tracking is a daily activity, not an annual event.
If we shipped English-only, the audience we'd reach first would be the audience that already has the problem solved relatively well. Splitwise is fine for them. The audience who actually needs us most would have to wait, or settle for a half-translated app.
Translation isn't a feature; it's an architectural decision
If you treat translation as something you bolt on at month 12, you build everything assuming English. The database fields are English. The category names are English. The error messages are formatted for English grammar. By the time you decide to translate, half your foundations need rewriting.
Solvory's database stores translatable fields in JSON columns from day one. Every category, currency, payment method, recurrence pattern, and UI string is admin-editable from a single page. Adding a 17th language is one row in languages.is_active = true away. The infrastructure is the feature.
RTL is not the same as flipping the text
Arabic and Hebrew don't just read right to left — the entire visual hierarchy flips. Icons that point forward should point backward. Progress bars fill in the opposite direction. The "back" button in a navigation header sits on the right, not the left. Most apps that "support RTL" just mirror the CSS and call it done. The result is uncanny — like reading a book where someone Photoshop-flipped the cover.
We handle RTL at the layout level: directional icons reverse, money formats use Arabic-Indic numerals where the locale prefers, dates render in the locale's calendar order. It's not perfect, and a native speaker can probably still find rough edges. But it's not a CSS hack.
The auto-translate compromise
Real talk: we don't have native speakers in 16 languages. The English copy is the source of truth; the other 15 locales are seeded by an OpenAI batch translation job, then cleaned up by community contributors and real translators when we can afford them. That's not as good as ground-up native copy. It's better than no localization at all, and the per-string admin UI lets us improve any specific phrase without a release.
This is the trade-off you accept when you ship in 16 languages on day one with a small team. The alternative is being English-only forever, which is a worse outcome for everyone except the engineer who wants their codebase to feel tidy.
What changes about who uses the product
The first month of usage data showed something we didn't expect: more than half of registrations came from non-English locales, with Arabic and Hindi in the top three. Those are users who would never have appeared in a typical "ship-in-English-then-translate" funnel — they would have bounced off the registration page.
Localization isn't a feature. It's a market-access decision. We chose access.
What's next
The roadmap from here is regional, not global: native payment-method names per country (so "Cash" becomes "Efectivo", "Hawala" becomes a real option in MENA contexts), local-currency formatting, region-specific blog posts in the source language. The infrastructure is there. The work is editorial.
If you're a native speaker of one of the supported languages and notice something that reads off, send it through the contact form. We read every one, and we ship corrections within a week.