From Tokyo to São Paulo: Making an AI Platform Global

A support message we couldn’t read

Three weeks ago, someone in Seoul sent us a message in Korean. We ran it through a translator: they wanted to schedule an agent to run every morning, but the time was wrong by nine hours. Our platform didn’t know what timezone they were in. It assumed UTC for everyone.

That was the moment we realized our product had a geography problem. Not just language — though we only supported four languages at the time. The whole stack assumed a user who speaks English, pays in dollars with a credit card, authenticates through Google, and runs everything in a browser. That described maybe 30% of our potential audience.

The other 70% were locked out by friction we’d built without thinking about it. The v3.0 UI redesign gave us a modular foundation to fix that.

The language gap

When we launched with four languages in week one, we thought we were ahead of the curve. English, Russian, Simplified Chinese, Traditional Chinese. That covers a lot of people. But it doesn’t cover a developer in Frankfurt, a student in Seoul, or a freelancer in Sao Paulo.

On February 21, we shipped six new locales: German, Spanish, French, Korean, Portuguese, and Brazilian Portuguese. Ten languages total. The i18n infrastructure we’d set up early made adding them straightforward — the hard part was what came next.

A translated UI is table stakes. The real question: what language does the agent speak? If a Korean user asks the agent to summarize a document, they expect a Korean summary. Not an English one with a translated button that says “done.”

So on March 8, we wired the user’s locale preference into every agent prompt. When you set your language to Spanish, the agent thinks in Spanish. Scheduled tasks, background jobs, everything. We also added timezone detection via an HTTP header on every request — which is how we fixed that nine-hour bug from Seoul.

Killing the subscription

Our billing infrastructure went in on day three. But the model was wrong for international users. Monthly subscriptions mean recurring currency conversion fees. A $15/month plan costs a Brazilian user an extra $2-3/month in bank fees alone. Every single month.

On February 15, we replaced subscriptions with pay-as-you-go credits. Credit packs from $5 to $100. No recurring charges. You buy what you need and use it until it runs out. We added per-model credit pricing the next day — different models cost different amounts, and you can see exactly what each request costs before you make it.

Every new account gets 20,000 welcome credits. Enough to run a few dozen agent tasks and decide if the platform is worth paying for. We added credit pack tiles with price comparison so users can see the per-credit discount at higher tiers.

This wasn’t just a pricing change. It was removing a barrier that made the product unusable for a significant chunk of the world.

Native payments on every platform

Credit packs only work if people can actually buy them. A web-only Stripe checkout covers desktop users with credit cards. It doesn’t cover the person on the train in Tokyo using their iPhone.

We built native in-app purchases for both platforms. StoreKit 2 for Apple, Google Play Billing for Android. The full flow: browse credit packs, tap to buy, confirm with Face ID or fingerprint, credits appear in your account. No redirect to a web page. No typing in card numbers on a phone keyboard.

The trickiest part was auto-refreshing the credit balance after an LLM response. When an agent finishes a task, it costs credits. The balance needs to update immediately, not on the next page load. We wired that up on February 21 — the same day we shipped the new languages.

Authentication without friction

We had Google Sign-In from the start. But on iOS, Apple Sign-In is what users expect. On February 22, we added it — one-tap authentication for anyone with an Apple ID, plus email linking for account recovery.

The bigger change was the auth modal. Before, tapping “sign in” on mobile opened a browser redirect. You’d leave the app, land on an external page, authenticate, get redirected back, and half the time lose your context. The app would reload from scratch.

On February 12, we replaced that with an in-app auth modal. Authentication happens inside the app. No redirect, no lost state, no confusion. It sounds like a small thing. It cut our mobile auth abandonment rate significantly.

The desktop question

Web apps are convenient. But for an AI agent platform, “convenient” has limits. You can’t run a scheduled task when the browser tab is closed. You can’t sync files between your local machine and the agent’s workspace without a clunky upload step.

On March 2, we shipped a desktop app. Browser profile sync means your agent knows your preferences without re-configuring. Local schedule execution means your 9 AM task runs at 9 AM even if you’re not in a browser. VFS file operations and a tool proxy mean the agent can read and write files on your machine through the same interface it uses in the cloud.

This was the piece that turned LikeClaw from a web tool into something you’d actually leave running. The same agent, the same workspace, the same scheduled jobs — but native on your desktop. We covered the multi-platform story earlier, and the desktop app is the natural extension of that work.

What’s next

Ten languages is a start. We’re looking at Japanese, Arabic, and Hindi next — each with its own layout and text direction challenges. Regional payment methods like PIX in Brazil and Kakao Pay in Korea are on the roadmap. And the mobile apps are getting closer to feature parity with the web and desktop versions every week.

Going global isn’t a feature you ship once. It’s a commitment to removing friction wherever your users are. We started with four languages and a credit card form. Now we have ten languages, four payment methods, three auth providers, and two native platforms.

The person in Seoul can schedule their morning agent in Korean, at the right time, and pay for it without leaving the app. That’s the bar.