Building for India: Latency, Cost, and Regional Nuance

I've spent my career building software from India, often for global clients. But building software for India is different — the constraints are different, the users are different, and the assumptions baked into most Western product thinking fail in ways that aren't always obvious until something breaks in production.

Some of this I learned early. Some of it I learned the hard way. All of it I wish had been written down somewhere when I started.

Why 200ms Matters More Here

On a reliable fiber connection in a major metro, an extra 200ms of API latency is annoying but tolerable. In India, that same 200ms can make your product feel broken — and here's why it compounds.

A large chunk of Indian users access services on congested mobile networks with high baseline latency. Your 200ms API call might arrive at 800ms by the time it reaches the device. Add UI rendering, and you're over a second. Add multiple interactions, and the product genuinely feels sluggish. I've seen user retention numbers that correlated almost perfectly with p90 latency in Tier 2 and Tier 3 city users — not because those users had lower expectations, but because the network conditions were fundamentally different.

The retry storm problem is underappreciated. Users on unreliable connections retry more. If a request times out, they tap again — sometimes twice, sometimes three times. Now you have multiple requests in flight, amplified load on your servers, and degraded experience for everyone in the session. I've seen this cause cascading timeouts in systems that looked fine in testing because we'd tested on office WiFi.

What I do about it: aggressive caching where any staleness is acceptable, optimistic UI updates that show immediate feedback while syncing in the background, edge deployment in Mumbai and Chennai (not optional — it's a night-and-day difference for anything doing real-time queries), offline-first architecture for anything that needs to work reliably, and request coalescing to batch small API calls. Every round trip is expensive. Minimize them.

Cost Sensitivity Is Not Poverty

I need to say this more directly than the polite version: Indian enterprise buyers are not cost-sensitive because they can't afford things. They're cost-sensitive because they've been burned by vendors who quoted a number, got them dependent on the product, and then restructured pricing. The skepticism is earned.

What I've actually observed, working with clients across Pune, Mumbai, and Bengaluru: total cost of ownership matters more than sticker price. Indian buyers calculate rigorously. They want to know implementation costs, training costs, ongoing maintenance burden, and — this is the one Western vendors consistently underestimate — exit costs. How hard is it to move data out? What happens if they need to switch vendors in 18 months? A cheap product with expensive operations and painful migration paths loses to a more expensive product with transparent, predictable costs.

Predictability beats low prices. Surprise bills are trust-destroying in a way that even high bills sometimes aren't. I've seen Indian enterprise teams pay significantly more than the usage-based alternative just to have a flat rate they could actually budget around. The unpredictability of usage-based pricing with poorly understood cost drivers is genuinely a dealbreaker for procurement teams that have been through it once.

ROI needs to be demonstrable and specific. "Increase productivity" doesn't close deals. Indian buyers want specific, measurable outcomes with clear timelines and a methodology they can validate. If you can't quantify the value in terms that their CFO will recognize, you're not winning the deal regardless of how good your product is. I've watched excellent products fail in the Indian market because the vendor's sales team couldn't articulate a concrete business case.

The first deal is often small — a pilot, a proof of concept, sometimes frustratingly limited in scope. But if you deliver on it, expansion follows and it's usually significant. Indian organizations tend to be loyal to vendors who prove themselves. The patience required for that initial phase is real, but so is the reward on the other side of it.

Localization Beyond Translation

Translating your UI to Hindi is necessary but nowhere near sufficient. Real localization goes deeper, and the gaps are more subtle than most product teams anticipate.

India has 22 official languages and hundreds more in daily use. "Localize to Hindi" misses users in Tamil Nadu, Kerala, West Bengal, and the Northeast — that's hundreds of millions of people. A Marathi speaker in Pune may actually prefer English over Hindi. This is not a niche edge case; it's the lived reality of multilingual daily life in most Indian cities. Don't assume a single regional language covers your market.

Script and input handling is where things get technically complicated fast. Many Indian languages use non-Latin scripts. Does your app handle Devanagari, Tamil, Telugu, Bengali text correctly? What about mixed-script input — the very common pattern where users switch between English and their native language mid-sentence, sometimes mid-word? I've seen authentication flows break on names that include regional script characters. I've seen address fields silently truncate inputs they didn't recognize. These aren't edge cases for the users experiencing them.

Name formats don't fit Western first/middle/last models. Some people have single names. Some have names with initials that expand differently in different professional versus personal contexts. Your user model has to accommodate this gracefully, not throw a validation error.

Indian addresses are famously unstructured. Landmarks matter more than street numbers — "behind the temple, second lane off MG Road" is a real, deliverable address. Your address validation logic should not reject inputs like this. I've seen food delivery integrations fail for entire neighborhoods because the address parser was built for American postal formats.

Numbers: India uses the lakh (100,000) and crore (10,000,000) system. Displaying "10,00,000" instead of "1,000,000" isn't a formatting bug for Indian users — it's correct. Financial dashboards that don't support Indian number formatting feel foreign in a specific, grating way to users who've grown up reading numbers differently.

Payment and Identity

The payment and identity infrastructure in India is genuinely world-class — but it's different enough from Western defaults that you can't just use whatever you built for the US market.

UPI dominates consumer payments. Credit card penetration is low compared to most Western markets. If your checkout flow doesn't support UPI, you're excluding the majority of potential users. This isn't a regional preference — it's the primary payment rail for most of the country.

For regulated industries, Aadhaar integration enables KYC and authentication at scale. It's often mandatory in fintech, lending, and insurance. The government APIs for identity verification, digital signatures, and document retrieval through the Digital India stack are sophisticated and worth learning. They're also much more capable than most Western teams expect.

Selling to Indian Enterprises

Decision cycles are long. Hierarchy matters — you need multiple stakeholders to align, budget cycles are rigid, and procurement processes are thorough. Planning for 6 to 12 month sales cycles on significant deals isn't pessimism; it's realism.

Relationships genuinely precede transactions. Cold outreach has low yield. Warm introductions, industry events, and referrals from existing clients open doors in ways that cold email simply doesn't. I've watched companies with excellent products struggle for years in the Indian market because they kept trying to run a playbook built for US enterprise sales.

Pilots are expected. Indian buyers want to see your solution working in their environment, with their data, before they commit. Be prepared to invest in this — treat the pilot as part of the sales process, not a favor you're doing for a potential customer.

Local support is non-negotiable. "Email us and we'll respond within 24 hours" does not cut it for Indian enterprise clients. Phone support, someone who understands the context and the time zone, and responsiveness during IST business hours — these matter in ways that are hard to explain to vendors who've never sold here before.

Building Teams Here

India has extraordinary engineering talent. The competition for it is also extraordinary — every major global tech company recruits here aggressively, and well-funded startups have raised the compensation bar significantly.

Annual attrition rates of 15 to 25% are common in Indian tech. This isn't a failing of Indian workers; it's a market reality. Build systems and processes that survive turnover. Document aggressively. Cross-train teams on critical paths. Single points of knowledge failure become single points of departure failure.

Post-pandemic expectations around remote work have solidified. Fully in-office mandates severely limit your talent pool. Hybrid models are the norm now, and they work reasonably well. Rigid policies don't.

Career growth matters enormously. Indian engineers are ambitious, and they're often navigating implicit pressures from family and community around career progression. If they can't see a concrete growth path in your organization, they'll find one elsewhere — usually within six months of realizing the ceiling is closer than they thought. Invest in career development and internal mobility as retention tools.

What This Has Taught Me

Building for India has genuinely made me a better engineer. The constraints force efficiency. The diversity of users forces flexibility in ways that building for a more homogeneous market doesn't. The scale forces robustness that you can't fake.

The products that win here aren't dumbed-down versions of Western products. They're products designed from the ground up for Indian realities — fast on slow networks, affordable and predictably priced, respectful of linguistic and cultural diversity, integrated with Indian infrastructure. That's a higher bar in some ways than building for a market with more forgiving infrastructure.

The discipline transfers. I've applied what I've learned here to projects in Southeast Asia, the Middle East, and parts of Africa where similar constraints hold. Once you've stopped assuming the ideal conditions, you build differently — better, I'd argue.