That constraint shaped the entire architecture of the WhatsApp order bot I built, starting from a single demo (a biryani restaurant) and generalizing it into something any local business could plug into.

The Wrong Way to Start

The first working version was hardcoded for one client: one menu, one set of business hours, one phone number, credentials baked into the code. It worked as a demo. It was structurally useless as a product — every new client would mean cloning the repo and editing source code.

That's not a business. That's a one-off project repeated badly.

The Fix: Config-Driven Architecture

The rebuild moved every client-specific detail out of code and into a single config.json:

{
  "business_name": "Karachi Biryani House",
  "menu": [...],
  "hours": { "open": "11:00", "close": "23:00" },
  "whatsapp_number_id": "...",
  "currency": "PKR",
  "tone": "friendly, casual Urdu-English mix"
}

The bot logic reads this config at startup and at runtime. Onboarding a new restaurant becomes: write a new config file, point a new WhatsApp Business number at the same deployment. No code changes, no redeploy of core logic.

This is the difference between a project and a product. A project solves one instance of a problem. A product solves the shape of the problem.

What Was Still Missing

Getting the config-driven structure right was necessary but not sufficient. A demo bot and a production bot differ in what happens when things go wrong, not in what happens when things go right.

No retry logic. If a Groq API call failed — rate limit, timeout, network blip — the conversation just died. The customer got no response and no error message. They assumed the bot was broken and left.

No structured logging. Debugging meant adding print() statements, redeploying, and waiting for the issue to recur. There was no way to see what had happened five minutes ago without it still being on screen.

No state persistence across restarts. Order-in-progress state lived in memory. A deploy or crash meant every active conversation lost its context mid-order.

Single point of failure on every external call. Meta's WhatsApp Cloud API, Groq's inference API — any hiccup in either one took down the whole flow with no fallback behavior.

Fixing It for Production

The retry pattern is simple but non-negotiable for anything calling an external API in a user-facing flow:

def call_with_retry(func, *args, max_retries=3, **kwargs):
    for attempt in range(max_retries):
        try:
            return func(*args, **kwargs)
        except Exception as e:
            if attempt == max_retries - 1:
                raise
            time.sleep(2 ** attempt)

Exponential backoff, hard cap on attempts, and — critically — a defined behavior on final failure. The bot needs to tell the customer "I'm having trouble right now, try again in a moment" rather than going silent. Silent failure is the worst failure mode in a conversational interface, because the user has no idea whether to wait or walk away.

For state, moving order-in-progress data to Redis instead of in-process memory meant a deploy or restart no longer meant losing every active conversation. This also opened the door to running multiple bot instances behind a load balancer later, since state isn't tied to a single process anymore.

For logging, replacing every print() with structured logging (logging module, timestamped, leveled) meant production issues could be diagnosed from log history instead of needing to reproduce them live.

What This Pattern Generalizes To

None of this is specific to WhatsApp bots or restaurants. The same shape applies to any tool meant to serve multiple clients from one codebase:

• Separate configuration from logic completely

• Assume every external API call will fail sometimes, and decide in advance what happens when it does

• Log enough that you can debug from history, not from live reproduction

• Keep state somewhere that survives a restart

The architecture that makes a bot sellable to a second client is rarely about adding features. It's about removing the assumptions that only held true for the first one.

Both work. They are not the same, and picking the wrong one for your use case costs you either money, latency, or accuracy — sometimes all three.

The Translation Layer Approach

This is the obvious first solution. User types in Roman Urdu or Arabic, you call an LLM API to translate it to English, then you embed the English version and search your English-indexed documents.

Query → Groq/OpenAI translate → English text → Embed → FAISS search

It works, and it's fast to implement if your index already exists in English. But it has real costs that don't show up until you're past the demo stage:

Per-query API cost. Every single search now requires an external API call before you even start searching. At scale, this is not free, and it's not optional — it's on the critical path of every request.

Latency stacking. Translation typically adds 300ms-1s before search even begins. Users feel this, especially compared to a direct embed-and-search flow.

Translation drift. LLM translation isn't deterministic. The same Roman Urdu query translated twice can come back slightly different, which means your search results aren't fully reproducible either.

A single point of failure. If the translation API is down, rate-limited, or slow, your entire search pipeline is down — even though FAISS itself is working fine.

I hit this directly: a translation call that worked for short queries started failing with 413 Payload Too Large once I was also stuffing retrieved hadith text into the same API call for answer generation. Two unrelated bottlenecks, same dependency, same outage.

The Multilingual Embedding Approach

The alternative: use an embedding model trained across multiple languages from the start, so you never need a translation step at all.

Query (any supported language) → Embed directly → FAISS search

I switched from all-MiniLM-L6-v2 (English-only) to paraphrase-multilingual-MiniLM-L12-v2 (50+ languages, including Urdu and Arabic). Same model size, same inference speed, no extra API call.

A query like "namaz ka tariqa" gets embedded into roughly the same vector space as its English equivalent "method of prayer" — close enough in cosine similarity for FAISS to retrieve relevant English-language documents directly. No translation hop, no external dependency at query time.

The Real Trade-off

The catch is upfront cost, not ongoing cost. Switching embedding models means your entire index is now invalid — every document needs to be re-embedded and the FAISS index rebuilt from scratch. For a corpus of 35,000+ documents, this took about 5-10 minutes on CPU. For a much larger corpus, this could be hours, and it's a cost you pay every time you want to upgrade the embedding model.

There's also an accuracy trade-off worth being honest about: multilingual models are generally weaker than language-specific models at any single language. If 95% of your traffic is English and 5% is Urdu, a dedicated English model with a translation fallback for the 5% might outperform a multilingual model across the board.

How I'd Decide

If you're building for a user base that's genuinely multilingual — not just occasionally typing in another language — multilingual embeddings are the better long-term architecture. The reindex cost is paid once. The translation layer's costs are paid on every single query, forever, for as long as the system runs.

I ended up using both in the same system: multilingual embeddings as the primary search mechanism, with the LLM translation step kept only for generating the final natural-language answer from retrieved context — a task where you genuinely need an LLM in the loop anyway.

Then I tested it the way my actual users would use it: in Roman Urdu.

"aurat ki namaz ka tariqa" returned almost nothing useful. Not because the hadiths weren't there — they were. The embedding model simply didn't understand Roman Urdu as a language. It was treating "namaz" as a meaningless token, not as the Urdu word for prayer.

This is the gap that breaks most RAG systems built for South Asian or Middle Eastern users: the embedding model is trained primarily on English, and Roman Urdu — Urdu written in Latin script — looks like gibberish to it.

Why This Happens

A standard embedding model like all-MiniLM-L6-v2 is trained on English text. It maps semantically similar English sentences close together in vector space. But "namaz ka tariqa" has no representation in that space — it's not English, and it's not standard Urdu script either. It's a hybrid the model was never trained on.

The naive fix — just embed the Roman Urdu query directly and hope for the best — fails silently. You get results, but they're not the right ones. Worse, there's no error to catch. The system looks like it's working.

The Fix: Translation Before Embedding

The pipeline needs an explicit step before the query ever touches FAISS:

User query → Detect language → If Roman Urdu: translate to English → Embed → Search

I used Groq's API with a fast model to handle translation. The key detail most people get wrong here: detecting Roman Urdu is not the same as detecting non-English text.

My first attempt used a simple ASCII-ratio check — if 85% of characters were ASCII, treat it as English. This failed immediately, because Roman Urdu is ASCII. "aurat ka namaz ka tariqa" passes an ASCII check with flying colors while being completely unintelligible to an English-trained model.

The actual fix was a marker-word approach:

ROMAN_URDU_MARKERS = {
    "ka", "ki", "ke", "ko", "ne", "se", "mein", "par", "hai",
    "hain", "namaz", "zakat", "roza", "hadith", "sunnat",
    "wuzu", "salat", "dua", "masjid", "quran", "allah"
}

def is_likely_english(query: str) -> bool:
    tokens = set(query.lower().split())
    if tokens & ROMAN_URDU_MARKERS:
        return False
    ascii_ratio = sum(c.isascii() for c in query) / len(query)
    return ascii_ratio >= 0.85

If the query contains common Roman Urdu function words or domain vocabulary, it routes to translation regardless of script. Only then do you fall back to the ASCII heuristic for genuinely ambiguous cases.

The Second Layer: Multilingual Embeddings

Translation solves the query side, but it adds latency and an external API dependency for every single search. The better long-term fix is switching the embedding model itself.

I moved from all-MiniLM-L6-v2 to paraphrase-multilingual-MiniLM-L12-v2 — same architecture family, same inference speed, but trained across 50+ languages including Urdu and Arabic. This means a Roman Urdu or Arabic-script query can match an English-embedded document directly, without a translation hop at all.

The trade-off: this requires rebuilding your FAISS index from scratch, since the vector space itself changes with the model. For a 35,000-document corpus, that's a one-time cost of about 5-10 minutes on CPU — trivial compared to the alternative of running translation calls on every query forever.

What I'd Tell Someone Starting This

If you're building a RAG system for a non-English-first user base, don't treat multilingual support as a feature to add later. Decide upfront whether you're translating queries or using multilingual embeddings — they solve the same problem differently, and retrofitting either one means touching your entire ingestion and query pipeline.

And test with real queries from real users, in the script and phrasing they'd actually type. Clean English test queries will tell you nothing about whether your system works for the people you're actually building it for