A government school teacher in rural Maharashtra was asked why her students had stopped using an otherwise well-regarded learning app. The answer had nothing to do with pedagogy. The app shipped a 4 MB JavaScript bundle before showing anything, the lessons were English-only with Marathi subtitles burned into video, and the video would not resume after a network drop. On a shared phone with a 1.5 GB daily data pack, that is not a product, it is an obstacle.
India has crossed 900 million internet users, and the overwhelming majority of new additions are non-metro, non-English-first, and mobile-only. Building for them is a set of engineering decisions, not a translation project.
Budget the Bytes Before Anything Else
Performance on a mid-range Android device over a congested 4G cell is a different problem from performance on office wifi. Some usable targets:
- Under 200 KB of compressed JavaScript on the critical path for the lesson view. Anything beyond that costs seconds of parse time on a device with a slow CPU, not just download time.
- A first meaningful render inside 3 seconds on a simulated Slow 4G profile. Test on the profile, not on your laptop.
- Audio-first content where possible. A 128 kbps audio track with synced slides carries most lessons at roughly a tenth the payload of video. For explanation-heavy subjects the loss is small.
- Adaptive bitrate with a low bottom rung. A 144p or 240p ladder step is not an embarrassment, it is what keeps the lesson playing.
- Resumable everything. Downloads, video position, quiz progress, and form state must survive a network drop, because network drops are the default condition, not the exception.
- Explicit offline download of a chapter over wifi, with a visible size before the tap. Learners on metered data will plan around it if you let them.
Regional Language Is Not a String File
India recognises 22 scheduled languages, and a platform serving school learners in Uttar Pradesh, Tamil Nadu, and West Bengal is running three different typographic and input problems at once.
Devanagari, Tamil, and Bengali scripts need proper shaping and font subsetting. A full Indic font file can run past 300 KB, so subset it to the glyphs your content actually uses. Text expands, often by 20 to 30 percent against English, which breaks fixed-width buttons and single-line labels designed on an English mock.
Machine translation of instructional content is where most projects go wrong. General translation is adequate for interface labels and badly wrong for subject terminology, where a mistranslated mathematical term teaches an error at scale. The workable pattern is machine translation followed by review from a teacher who teaches that subject in that language, with a locked glossary of terms.
Voice input deserves more attention than it gets. A learner who is not confident typing in their own script will happily speak a question, and speech recognition in major Indian languages has become good enough for search and doubt entry even where it is not good enough for dictation.
Design for a Shared Device
Assume the phone belongs to a parent and is available for ninety minutes in the evening. That shapes the product. Sessions should be short and self-contained, five to ten minutes, so an interrupted session is not a lost one. Login should not demand an email address that the learner does not have. Progress should be tied to a profile that survives a handset change, because handsets change often at this price point.
Storage matters too. A device with 32 GB and 400 photos on it will evict your cached content without warning, so treat local storage as a cache that can vanish and re-fetch gracefully rather than as a database.
At Invexa, we design education products against constrained devices and Indic scripts from the first build rather than retrofitting them, since a lesson that will not load on the network the learner actually has is not a lesson at all.