Building AI products for Southeast Asia

Most AI products that land in SEA were built in California or London. They were tested on English-speaking users with fast internet, a web browser, and a cultural expectation of AI-powered interfaces. They fail here not because the technology is wrong but because the assumptions are wrong — about language, about infrastructure, about trust, and about which channel your users are actually on.

The language problem is not translation.

The first mistake is thinking that adding Bahasa Indonesia or Tagalog or Thai to your LLM's prompt is a localisation strategy. It is not. Language localisation at the model level solves only the simplest part of the problem. The harder problem is code-switching — the way real users in SEA mix languages in a single message, often within a single sentence.

A customer service query in Indonesia might arrive as: "halo, I want to check my order status dong, ordernya belum sampai padahal udah 3 hari." That sentence mixes formal Indonesian, colloquial particles, and an English loanword in a structure that is grammatically coherent to any Indonesian speaker but will produce unreliable results from a model trained primarily on formal, monolingual text. The model might parse the Indonesian correctly. It might parse the English loanword correctly. What it will frequently get wrong is the pragmatics — the implication that "belum sampai padahal udah 3 hari" (not arrived even though it has been 3 days) signals frustration that should trigger escalation handling, not just a status lookup.

This is not a problem you solve at the model level by adding more training data. It is a problem you solve at the product level by designing intent detection that is robust to mixed-language input, by testing with real user messages not synthetic ones, and by building fallback paths that activate when the model's confidence is low rather than letting it guess.

The register problem is equally significant. Most large language models are trained on formal text. Most SEA users write informally, with dialect vocabulary, abbreviations, and colloquial contractions that are not in the formal training data. A model that performs well on formal Indonesian customer queries will perform noticeably worse on the way actual customers write. The gap is rarely caught in testing because test inputs are typically written by someone who writes formally.

Infrastructure is not uniform across SEA.

Singapore has infrastructure comparable to any major city. Jakarta has infrastructure comparable to any major city. But your market in SEA is almost certainly not only Singapore and Jakarta. The moment you reach into tier-2 cities — Surabaya, Medan, Cebu, Chiang Mai, Da Nang — you are building for users with median connection speeds significantly lower than your assumptions, and with phones that are two to four generations behind the flagship devices your team uses for testing.

The practical implications: your AI product cannot require a fast connection to function. Long LLM inference chains with multiple round-trips to a remote server produce visible latency on a 4G connection in a city with congested spectrum. Users in these markets will abandon the interface before the response arrives. The solution is aggressive response streaming — showing partial responses as they generate — and designing UX that is forgiving of latency rather than assuming instant response.

File upload features deserve particular scrutiny. A feature that asks users to upload a document for AI analysis assumes the document is already digital, the connection is fast enough to upload it reliably, and the user has the technical fluency to navigate a file picker. In practice, a significant portion of your SEA tier-2 user base will have documents as phone camera photos, upload on a congested connection, and is unfamiliar with the file upload pattern. Design for the camera capture path as the primary flow, not the edge case.

WhatsApp is the platform, not your web app.

If your AI product reaches users through a web application and expects them to visit a URL, open a browser, and navigate your interface, you have already lost a large segment of your SEA addressable market. WhatsApp has 2 billion monthly active users globally, and in SEA markets — Indonesia, Malaysia, Philippines, Singapore — it is not just a messaging app. It is the primary digital interface for a significant portion of the population. Shopping, customer service, appointment booking, payments, and information-seeking all happen on WhatsApp before they happen anywhere else.

Building your AI product's primary interface as a WhatsApp chatbot is not a workaround or a compromise. For many SEA use cases, it is the correct primary architecture. The WhatsApp Business API gives you access to conversation history, rich media (documents, images, buttons), and a user base that already understands how to use the interface and does not need to learn a new one.

The constraints are real: WhatsApp limits message length, does not support all interface patterns, and has a 24-hour customer service window that forces you to think carefully about asynchronous vs. synchronous conversation design. But these constraints push you toward simpler, more direct interactions — which tend to perform better for AI-mediated interfaces than feature-rich web apps that try to do too much in a single session.

Trust and transparency operate differently here.

AI transparency expectations vary significantly across markets, and the SEA default is not the US default. In US consumer markets, there is a widespread assumption that AI-mediated interfaces are ubiquitous and that users are broadly comfortable with undisclosed AI. This assumption does not transfer cleanly to SEA markets, particularly for financial services, healthcare, and any context where the stakes of a wrong answer are material.

In markets like Indonesia and the Philippines, disclosing AI involvement tends to build trust rather than reduce it — particularly when paired with a clear escalation path to a human. The fear is not of AI per se; it is of being deceived. A chatbot that presents itself as a human representative and is later revealed to be an AI generates significant backlash. An AI that is clearly disclosed, explains what it can and cannot do, and offers a fast path to a human when it cannot help is perceived as more trustworthy than a human representative who is difficult to reach and inconsistent in their answers.

There is also a regulatory dimension. Several SEA markets are developing AI disclosure requirements for financial services and healthcare applications. These are not yet uniformly enforced, but building disclosure in from the start is cheaper than retrofitting it when the regulator asks. If your product handles anything adjacent to financial advice, insurance, or health information, disclose AI involvement explicitly and document your disclosure approach.

What to build differently from the start.

The list of adaptations is not long, but each one requires a deliberate decision before you build rather than an expensive retrofit after you ship. Design for mixed-language input by testing with real user messages in the languages you are targeting, not synthetic test inputs written in formal register. Build for low-bandwidth by streaming responses and optimising for mobile-first, not desktop-first. Choose WhatsApp as a primary delivery channel, not an afterthought. Disclose AI involvement explicitly and build escalation to humans as a core feature, not an emergency exit.

The deeper adaptation is attitudinal. Most AI product teams in SEA are building products they personally use — they are the Singapore-based, English-first, fast-internet users their product is inadvertently optimised for. Building for the tier-2 city user in Indonesia or Philippines requires deliberate empathy work: user interviews in local languages, testing on mid-range Android devices on constrained connections, and org-level permission to make the product simpler rather than more sophisticated.

• 01
  Test with real user messages, not synthetic inputs. Collect actual messages from your target users before you evaluate your AI's performance. Code-switched, informal, abbreviation-heavy inputs look very different from what your engineering team writes when constructing test cases.
• 02
  Stream responses and design for latency tolerance. Do not require a fast connection to get a usable response. Show partial responses as they generate. Design loading states that communicate progress, not just spinning indicators that time out on a congested 4G connection.
• 03
  Build WhatsApp as a primary interface, not a last resort. For most consumer AI use cases in SEA, WhatsApp is where your users already are. Building a web app first and WhatsApp second often means building the wrong thing first.
• 04
  Disclose AI involvement and build escalation in from day one. Explicit AI disclosure increases trust in SEA markets. A clear, fast path to a human is not a fallback — it is a feature that makes users more willing to engage with the AI in the first place.
• 05
  Test on mid-range Android, not your MacBook. The typical device in your SEA market is a mid-range Android phone that is a few years old, with far less memory than the phone your team tests on. If your product only feels good on the device in your pocket, it will not feel good to most of your users.

Frequently asked questions.