A product built in Bengaluru is usually built on a fast, stable connection, by engineers with current hardware, in a room where the network never wavers. The people who determine whether it grows are frequently on an intermittent mobile connection, on a device several generations old, with limited storage and an operating system that aggressively kills background processes. The gap between those two experiences is where most Indian consumer products quietly lose their users, and it does not show up in any dashboard that measures averages.
The first correction is measurement. Median load time flatters you; the useful numbers are the seventy-fifth and ninety-fifth percentiles, segmented by device class and connection type. A product where the median is two seconds and the ninety-fifth percentile is nineteen does not have a fast product with a few outliers — it has a fast product for some people and an unusable one for others, and the second group will churn without complaining.
The second is that unreliable is different from slow, and the two need different designs. Slow is a performance problem, solved by sending less. Unreliable is a state problem, solved by assuming any request may not complete and designing what the user sees when it does not. An action that succeeds locally, queues, and reconciles later is the correct pattern for anything a user initiates. An interface that spins indefinitely because someone assumed the request always returns is the commonest failure.
Payload size is the lever with the largest effect and the least glamour. Images dominate most Indian applications, and serving appropriately sized, modern formats with real compression will beat almost any framework-level optimisation. After that comes what loads before the user can do anything: fonts, analytics, tag managers, chat widgets, experiment frameworks. Each was added for a reason and none of them were added by someone measuring their cost on a slow connection.
Language deserves more than a translation pass. Indian users move between languages within a single session, type in transliterated script, and search for things in one language that were entered in another. Font rendering for Indic scripts is heavier than for Latin, input methods differ, and text expands unpredictably in layouts designed around English. Treating this as a localisation task assigned late produces an interface that technically supports a language and practically discourages it.
The cheap test that finds most of these problems takes an afternoon. Get a mid-range Android phone that is three or four years old, throttle it to a slow network in the browser's developer tools, and complete your product's core journey on it. Almost every team that does this finds something they would not have found any other way, and finds it before a user does.
