SaaS · 4 min read

    Designing a multi-tenant SaaS for Indian SMBs: lessons from ChatYug

    Tenant isolation, language fallbacks, GST-aware billing, and the parts of "SaaS 101" that don't survive contact with India.

    By Nishant Sonawala, Founder, SICI TechnologiesPublished Updated
    Short answer

    Building ChatYug, our WhatsApp Business SaaS for Indian SMBs, taught us that multi-tenancy in India is less about clever infrastructure and more about defaults: isolate every tenant by ID at the database layer from day one, design billing around GST invoices and prepaid wallets rather than card subscriptions, support Hindi and Gujarati with English fallbacks, and build onboarding for owners who run their business from a phone.

    What ChatYug is

    ChatYug is SICI Technologies' own multi-tenant platform for the WhatsApp Business API: a shared inbox, broadcast scheduler, template manager, chatbot flows and commerce catalogues, used by small and mid-sized Indian businesses. Every lesson below came from running it in production, not from a whiteboard.

    1. Choose the tenancy model early — and isolate in the database

    There are three common models: a database per tenant, a schema per tenant, or shared tables with a tenant ID on every row. For thousands of small tenants, a database per tenant becomes an operations problem very quickly. We use shared tables with a mandatory TenantId column.

    The important part is where isolation is enforced. Every stored procedure takes the tenant ID as its first parameter and filters on it; the API reads the tenant from the signed-in user's token, never from the request body. A developer cannot forget the filter in a controller because controllers never write SQL.

    • Every table that holds customer data has TenantId, indexed and part of most composite keys.
    • Unique constraints include TenantId, so two businesses can both have a contact called "Ramesh" and a template called "order_update".
    • Background jobs (broadcasts, scheduled sends) carry the tenant ID explicitly and re-check it before acting.
    • Admin tools that cross tenants are a separate, audited path — never the normal API with a flag.

    2. Billing in India is not Stripe-shaped

    Textbook SaaS assumes a card on file and a monthly subscription. Many Indian SMB owners prefer UPI, pay in advance, and need a proper GST invoice for every payment for their accountant.

    • Prepaid wallet plus plan: owners top up via UPI or net banking, and usage (such as WhatsApp conversation charges) is deducted from the balance.
    • GST-compliant invoices generated automatically, with the customer's GSTIN, place of supply, and the correct CGST/SGST or IGST split.
    • Low-balance alerts sent on WhatsApp itself, because that is where owners actually look.
    • Grace periods instead of hard cut-offs: a broadcast already scheduled for a festival sale should not silently fail at midnight.

    3. Language: support three, design for fallbacks

    Our users and their customers switch between English, Hindi and Gujarati, often in the same conversation. Interface strings live in translation files from day one, but the harder part is content the tenant creates: templates, quick replies and bot answers.

    • Every tenant-authored message can hold language variants, with an explicit fallback order (for example Gujarati, then Hindi, then English).
    • Search and contact matching are tested on Indic scripts and on Romanised Hindi and Gujarati, which customers type far more than native script.
    • Dates show in IST and Indian formats; amounts in INR with lakh and crore grouping.

    4. Onboarding is a phone call, not a wizard

    Getting a business onto the WhatsApp Business API involves Meta Business verification, a phone number, display-name approval and message templates. A self-serve wizard alone loses most owners at the verification step.

    As an Official Meta Business Tech Provider, we can run embedded signup directly. We pair it with a short guided call and pre-approved starter templates for common needs (order updates, appointment reminders, payment links), so a new tenant can send real messages on day one.

    5. Noisy neighbours are a product problem

    In a shared system, one tenant sending a 50,000-message festival broadcast must not slow down another tenant's live support chats. We separate interactive traffic from bulk traffic into different queues, rate-limit each tenant against their own Meta messaging tier, and process bulk sends in batches that yield to interactive work.

    6. Audit everything a tenant can be billed or blamed for

    When a customer says "we never sent that message" or "why was I charged", the answer needs to be one query away. Every send, template change, broadcast and wallet movement writes an audit row with tenant, user, time and source (web, mobile, API or bot).

    What we would do the same way again

    1. Tenant ID enforced in stored procedures from the first migration.
    2. Prepaid wallet and GST invoicing before any card subscription.
    3. Language variants on tenant content, not just on the interface.
    4. Separate queues for interactive and bulk messaging.
    5. Human-assisted onboarding for the first week.

    Planning a SaaS product for Indian businesses? We build multi-tenant platforms with these defaults built in. Send us a short brief.

    Related reading

    Ready to start?

    Send us a one-paragraph brief. We respond within 4 business hours.

    No obligation · NDA on request · We reply within 4 business hours.