Most coverage of "AI for India" treats the subject the way Silicon Valley treats emerging markets — translate the product, localize the UI, and you're done. Six months of production deployment of 7S Samiti, our adaptive AI tutor for rural Indian students, taught us that this approach gets you maybe 5% of the way to a working product.
The other 95% is engineering for the actual constraints of rural India: a ₹1,500 phone, 32 GB of total storage shared with WhatsApp and the camera, 2G most of the day with bursts of 4G when the family travels to the nearest town, and a primary user who is either bilingual in Hindi-English Roman script or wants to interact entirely in voice.
Here's what we learned at Xenotix Labs.
Constraint 1: storage is the gatekeeper
The phones our users own do not have room to download a 600 MB app. They barely have room for our 80 MB app. We hit storage limits constantly.
Fix: split the app into a tiny installer (~20 MB) plus on-demand content packs that the user can opt into per subject. When a student finishes Class 8 Mathematics, the next time they have Wi-Fi at school, the Class 8 Science pack downloads. When they finish Science, Math is auto-evicted.
This is uncomfortable engineering. You have to track which content is on which device, which device has been seen recently, and which packs the student is most likely to need next. We log usage telemetry (locally first, synced when possible) to drive eviction policy intelligently.
Constraint 2: 2G changes everything
A 2G connection is ~50 KB/s on a good day. A 1 MB image takes 20 seconds. A 5 MB video takes 100 seconds.
We stopped using images for anything that could be expressed in HTML/CSS. Math equations: KaTeX, not screenshots. Diagrams: SVG, not raster. Animations: pre-rendered Lottie JSON files (smaller than GIFs), often under 50 KB.
Videos for lessons are streamed at 240p with adaptive bitrate. Each lesson has a "text-only" fallback the student can toggle on a slow day.
Constraint 3: voice over text
Our primary users are 11- to 14-year-olds who are still building literacy. Typing English on a touchscreen is slow. Typing Hindi via transliteration is even slower. Voice is faster, more natural, and more accessible.
We use on-device speech-to-text where possible (Android's offline STT works surprisingly well for Hindi-English code-switching), with a server fallback when local fails. The student speaks their question, the AI tutor responds with both audio and text. The text is there for re-reading; the audio is there for first comprehension.
Voice has a free side-effect: it's the only way the app works for partially-literate users. We didn't plan for that audience initially. They became 12% of monthly active users.
Constraint 4: the LLM in the middle
The AI tutor generates personalized quizzes, explanations, and study notes from the student's question. Standard LLM territory. The complications:
- Latency. A 4-second LLM response feels instant on Wi-Fi and unbearable on 2G. We stream the response token-by-token, even on 2G. The student sees the first words within ~1 second; the rest fills in as the network allows.
- Cost. A 7B-class self-hosted model handles 60% of queries; we route only the hard ones to a frontier model. Per-user daily token budget capped at the level a self-supporting student would tolerate.
- Curriculum alignment. The tutor must stay aligned with NCERT (or equivalent state board) curriculum. We retrieval-augment every prompt with the relevant chapter context from a vector store of textbook content the student has selected.
- Hallucination is a child-safety issue. A wrong math answer is bad. A wrong history fact is worse if a child memorizes it. We never let the LLM answer factual questions without retrieved context, and we surface a "I'm not sure" UI when confidence is low.
Constraint 5: offline is the default
The app must work entirely offline for the first 3 days. Otherwise, families with limited mobile data won't enroll their kids.
When the student installs the app, the installer downloads the first 50 lessons of the chosen subject and the on-device classifier model. From there, the AI tutor can generate quizzes, score them, and explain answers entirely on-device using a small distilled model.
The more capable LLM kicks in when the network is available. The student doesn't notice the boundary; lessons feel continuous regardless.
Constraint 6: trust is built in person
You cannot acquire users in rural India through Instagram ads. The trust gap is too wide. We work with local school teachers, NGOs, and panchayat-level community members. Our "onboarding" is a 30-minute session at the school where a teacher walks 10 students through their first lesson together.
We ship features for those teachers: a teacher dashboard (works on a basic Android), bulk-enroll flows, classroom-mode that mirrors a student's screen so the teacher can help with a stuck question. These features have nothing to do with AI; they're 100% of why the AI works in the field.
Stack summary
- Mobile: Flutter (offline-first, ~80 MB base + on-demand content packs)
- Web: Next.js (teacher and admin dashboards)
- Backend: Node.js + PostgreSQL
- AI Layer: mix of on-device distilled model + self-hosted 7B for routine + frontier model for hard
- Speech-to-text: Android offline STT primary, server fallback
- Content: SVGs, KaTeX, Lottie, 240p adaptive video
- Architecture: Microservices (auth, content, tutor, telemetry)
- Deployment: AWS
- Testing: Unit → Integration → Production + airplane-mode QA + 2G emulation
What we'd tell other teams building for emerging markets
- Storage budget is your #1 design constraint. Build for 100 MB total or you're not in the game.
- Voice is a feature, not a nice-to-have. Often, it's the entire UX.
- Cache aggressively, evict gracefully. Show the student progress on what's downloading.
- Test on the actual phone. Borrow a friend's old Redmi 7. Open the app there. Cry. Fix.
- Build for offline-first. Sync is second. Reverse this and you'll burn months.
- Local trust is the acquisition channel. Engineer for the teachers who'll evangelize you.
Building for emerging markets, rural India, or low-resource environments?
The playbook for premium-market apps is different from the playbook for budget-phone, low-bandwidth, partially-literate audiences. If you're building in this space, Xenotix Labs has shipped Flutter apps across rural education, dairy delivery, and field-work apps. Reach out at https://xenotixlabs.com.
Top comments (0)