पाठशाला Pathshala · उत्पाद Utpād, The product · Lesson 12 · Build
Building for low-end Android and patchy networks
The customer has a cheap Android phone with 2 GB of memory, a connection that drops and a family who share it. Design for that phone first and set budgets that keep the product usable.
Pathshala, The Founder Library · 11 October 2026 · 7 min read
The product was built on a laptop with sixteen gigabytes of memory, tested on the founders’ phones over office Wi-Fi, and demonstrated in a meeting room in Bengaluru. It will be used by a pharmacist in Nashik on a two-year-old phone with a cracked screen, a nearly full memory and a data pack that slows to a crawl in the afternoon. Those are two different products, and only the second one has customers.
This lesson is about building for the second. It describes the phone and the network the median customer actually has, sets the performance budgets that define an India-first product in numbers a team can test, lays out the patterns for a connection that drops and a phone that is shared, and ends with a test lab that costs less than one flagship and a checklist for every release.
Who is actually holding the phone
Alex Russell’s annual analysis of the performance inequality gap is the best public attempt to describe the median device and network worldwide. For 2024 his baseline phone is one sold new at the global average selling price of mid-2020 to mid-2021, about $350 to $375, a Galaxy A51 or Pixel 4a, and his baseline connection at the 75th percentile is 7.2 Mbps down, 1.4 up and 94 ms round-trip. He finds devices in that range are 15 to 25 per cent as fast as those carried by programmers and their bosses, and that the gap is widening: in his words, inequality is growing faster than the bottom end can improve.
That is a global baseline. A product sold to kirana owners, field agents, small clinics or students in tier-two and tier-three cities should assume its own users sit below it: older phones, cheaper phones, less memory, more of the day on a weak signal. Google’s own documentation shows how low the floor goes. Android (Go edition), the configuration for entry-level phones, needs only 512 MB of memory on Android 8.1 to 10, 1 GB on Android 11 and 12, and 2 GB on Android 13, and Google warns developers that Go devices carry significant performance, network and battery limitations.
The rule that follows is simple and almost always broken. The test phone is the customer’s phone, not the team’s. Every decision about frameworks, image sizes, animations and libraries is made against the cheap phone on a weak connection, and the flagship is the device on which the product is merely faster.
The budgets, in numbers
A budget is a number the team agrees in advance and checks automatically, so performance stops being a matter of taste. Four sets matter. For the web, Google’s Core Web Vitals set good at a largest contentful paint within 2.5 seconds, interaction to next paint of 200 milliseconds or less and cumulative layout shift of 0.1 or less, all measured at the 75th percentile of page loads. For what you send, Russell’s 2024 budget for a three-second first load on his baseline is about 365 KiB of compressed JavaScript and 365 KiB of markup for a JavaScript-heavy app, and about 75 KiB of JavaScript for a content site that leans on markup. A modern framework with a few analytics scripts can exceed the first figure before a line of product code is written.
For Android apps, Android vitals treats a cold start of five seconds or longer as excessive, a warm start of two seconds or longer and a hot start of 1.5 seconds or longer. For stability, Google Play’s bad-behaviour thresholds are a user-perceived crash rate of 1.09 per cent and an ANR rate of 0.47 per cent averaged across devices, and 8 per cent on any single phone model. Above them, Play may reduce the app’s visibility and show users a warning on its listing, judged on the last twenty-eight days. On a low-end phone the per-model figure is the one to watch: an app can look fine on average and be unusable on the one handset your largest customer issued to every field agent.
Designing for the network that drops
A patchy connection is not a slow one. It works, then it does not, then it half-works, and the half is where products break. Queue every write locally and send it when the connection allows, so the user can carry on. Make every write safe to retry with an idempotency key: the request that timed out on the phone has often succeeded on the server, and a retry without a key books the appointment twice or charges the customer twice. Open with what you have: cache the main screens and show them with the time they were last updated rather than a spinner. Resume uploads from where they stopped instead of from zero. Send less: images sized for the screen and compressed on the server, data paged, fonts limited to what the language needs.
For messages that must arrive, such as an OTP, a payment confirmation or an appointment reminder, have a fallback outside the app. An SMS or a WhatsApp message reaches a phone the app cannot, and for many users it is the channel they trust more. Design the first session around the same reality, as [the activation lesson](/library/activation-first-session-that-decides) argues: phone number and OTP, auto-read where the platform allows it, and nothing large downloaded before the first result.
Shared phones and full storage
In many households and small businesses one phone serves several people: the shop phone at the counter, a parent’s phone used by a student for classes, a handset issued to a team on rotating shifts. Ask at onboarding whether the phone is shared, offer a quick switch between users or a PIN on sensitive screens, and never assume the person who signed up is the person now holding it. A product for payments or health records needs this from the first version.
Storage is the other constraint. A phone that is nearly full is a phone whose owner is deciding what to delete, and a large app with a growing cache is the obvious candidate. Cap the cache, clean it, and make sure the app still works when the user clears its storage. Low memory has a related effect: the system kills background apps often, so an app that loses the half-filled form when the user switches to WhatsApp to check a number will lose the user too. Save state as the user types and restore it on return.
Two more decisions follow from the same phone. App or web: an installed app competes for storage and must be updated, while a well-built web app costs nothing to keep and opens from a WhatsApp link; for a product used weekly rather than hourly, the web often wins, and a small app can come later. Language and type: Indian scripts need fonts, and a full font family for each language is heavy. Load only the scripts and weights the user needs, rely on the phone’s system fonts where they render the script well, and test every screen in the longest language you support, because a Tamil or Malayalam label that fits nowhere breaks a layout that looked finished in English.
The test phone is the customer’s phone. The flagship is only the device on which the product is faster.
A test lab for the price of one flagship
Russell suggests a refurbished Galaxy A51, around $150, or a Nokia G100, around $100, as test phones for the global baseline. For an Indian product buy two or three handsets that match your own users: look at the device models in your analytics, buy the most common models below the median and one from the bottom of the list. The cost is less than one flagship, and the phones should sit on a desk where the whole team uses them, not in a drawer.
Add network conditions. Throttle the connection to a weak profile in the browser’s developer tools or on the device, run the key flows with the connection cut halfway through, and walk the product on a real afternoon data pack at least once a month, ideally outside a metro. Read real-user monitoring and Android vitals by device model, because averages hide the phone on which the product does not work. Every release ships only after a day on the cheap phone, a rule that belongs in the [weekly release train](/library/shipping-weekly-cadence-that-compounds).
The monthly performance review
On the first Monday of each month, in thirty minutes: read the Core Web Vitals or Android vitals for the last twenty-eight days by device model, and list every model above a budget. Check the size of the app download and of the first web load against their budgets and find what grew. Pick the single worst flow on the cheapest test phone and give it one engineer for a week. Then tick the checklist again for the coming release. A team that does this every month keeps a product that works for the customers it has; one that does not finds out from the reviews.
The thresholds are Google’s and Russell’s as published when checked in October 2026; they are revised from time to time, so read the current figures before setting your own.
Sources
- Alex Russell, The Performance Inequality Gap, 2024, Infrequently Noted, January 2024
- web.dev, Web Vitals
- Android Developers, Android vitals — Crash and ANR bad-behaviour thresholds. Checked October 2026.
- Android Developers, App startup time
- Android Developers, Android (Go edition)