Shipping one product for India, UAE and Oman

A good share of our work runs across India, the UAE and Oman — a Gulf CNC distributor among others. Serving all three from one product is very doable, and the mistakes are consistent enough to list.

The failure mode is not technical complexity. It is a product that feels obviously written for somewhere else.

Decide the region before anything renders

Region is not a language setting or a currency dropdown buried in the footer. It is a top-level context that determines currency, payment methods, tax display, delivery promise, contact number, business hours and legal text.

Detect a sensible default, show clearly which region the visitor is in, and make switching a single visible action. Never guess silently and never lock someone in — expatriate buyers browse across regions constantly.

Engineering shape: one region value flows through the application. Every price, phone number and promise reads from it. If any of those is hard-coded anywhere, you have a bug waiting for a customer to find.

Currency: store, do not convert

The tempting shortcut is one base price converted at runtime. It produces prices like ₹4,732 equivalent, it ignores that Gulf buyers expect round numbers, and it changes your pricing every time the market moves.

Store an explicit price per region. Review quarterly. Format properly — grouping and symbol placement differ, and Indian digit grouping is not the same as Western grouping. Getting that wrong signals sloppiness immediately to the audience it affects.

Payments: one interface, several providers

Indian checkout is UPI-first, with cards and netbanking behind it. Gulf checkout expects local card schemes and regional wallets, and cash on delivery remains meaningful in parts of the region.

Do not try to serve both with a single gateway. Build a thin payment layer — create an intent, confirm, handle a webhook, refund — and put providers behind it. Route by region.

Your reconciliation is now per provider, so make sure your finance workflow can handle that before launch, not after the first month’s statements arrive. The operational realities are much like those in the Razorpay and WhatsApp playbook, multiplied by the number of markets.

Tax and invoicing differ more than the tax rate

India needs GST fields, place of supply, HSN codes and specific invoice formatting. Gulf markets have VAT with their own rules and their own required invoice content.

Two practical consequences. Your invoice template must be per region, not a single template with a swapped percentage. And your data model must record which regime applied at the time of sale, because your accountant will ask about a transaction from eleven months ago and “we changed the template since” is not an answer.

Language, and the right-to-left question

English-first is usually viable for B2B across all three markets. Consumer products, government-adjacent work, and any market where competitors rank on Arabic terms change that calculation.

The important decision is structural rather than linguistic: build your layout so direction can flip. Use logical CSS properties — start and end rather than left and right — from day one. Retrofitting a right-to-left layout into a codebase built entirely on physical directions is a genuinely miserable project. Doing it correctly from the start costs almost nothing.

Also plan for text expansion. Translated strings are frequently longer than the English, and a button designed to fit exactly one word will break.

Time, dates and the working week

Three timezones, and the Gulf working week does not match India’s. This matters more than teams expect:

• Support hours and “we will respond within one business day” promises
• Scheduled notifications, which should never arrive at 3am local time
• Delivery estimates that must skip the correct non-working days per region
• Reports, which should be readable in the reader’s local time

Store everything in UTC, render in the viewer’s zone, and put the working-week definition in configuration rather than in code.

Content that is regionally true

The unglamorous part, and the part that most affects whether a buyer trusts you.

Show the local phone number, in the local format. Name the actual delivery timeframe for that region. Reference local certifications and local case studies where you have them. Do not display an Indian address on a page selling to Muscat unless you also explain the local presence.

For search, this means real regional pages rather than one page with a swapped currency symbol. A page that names the emirate, the local service terms and local proof will outrank a generic page for local intent — the same logic as the SEO playbook, applied per market.

Data residency and privacy per region

Know where your data sits and which rules apply. Indian obligations under the DPDP framework are not identical to Gulf requirements, and your inventory should record region alongside every category of personal data. We covered building that inventory in DPDP compliance for a small team — the structure extends cleanly to multiple jurisdictions.

The architecture in one paragraph

One codebase. A region context resolved early. Region-scoped configuration for currency, tax, payment provider, contact details, working week and legal text. Prices stored per region. A payment abstraction with providers behind it. Logical CSS properties everywhere. Content authored per region where it matters and shared where it does not.

That is not a large amount of extra engineering — perhaps 10 to 15% on top of a single-market build — provided it is designed in from the start. Bolted on afterwards, it is a rewrite.

Planning a launch across India and the Gulf? Tell us the markets and the product and we will map what changes per region before you commit to a build.