A multilingual-education platform that puts tribal-language teaching content in the hands of early-grade teachers — authored once, delivered offline to the classroom.
Early-grade children in Bastar learn best in their home language before bridging to Hindi. Bhasha Setu gives their teachers a pocket resource — vocabulary, classroom phrases, audio, stories and practice activities in the local tribal language — that works on a low-end phone, with or without a signal.
It is built for the Language & Learning Foundation as two connected products: a Flutter mobile app the teacher uses, and a web content studio the LLF team uses to author and publish that content. The two are joined by a single, frozen data contract — so what an author builds is exactly what a teacher sees.
Authors work in the Content Studio; teachers learn in the app. Content is compiled into versioned, self-contained “packs” that the app downloads once and runs entirely offline.
The app onboards a teacher in under a minute, then becomes a self-contained learning companion that keeps working when the network doesn't.
A one-time code (SMS) signs the teacher in — no passwords. The session is held securely on the device and persists for weeks, so they rarely re-authenticate.
Courses (Language Fundamentals, Classroom Talk…) are broken into modules and bite-size activities, laid out as a clear path with progress, XP and badges.
Listening quizzes, flash cards, matching, word clouds, fill-in-the-blank, dialogue building, picture labelling, pronunciation, audio narration and more — each rendered from authored content.
Content packs (including audio and images) download once and run with no connection. Progress is saved locally and synced back when a signal returns.
Why offline-first matters here: Bastar classrooms have intermittent connectivity. The app never blocks a teacher on the network — every screen works from on-device data, and syncing is a background convenience, not a requirement.
LLF's content team works in a tailored web admin. Every activity type is defined once as a schema, and the studio turns that schema into a friendly form — so authors fill in fields, not raw data.
One form engine reads each activity's definition and renders the right inputs — text, number, options, a media picker for audio and images — for all twelve types and any added later.
While editing, authors see the activity render exactly as the app will play it — the same engine, embedded in the studio — so what they build is what teachers get.
Content moves Draft → In review → Approved → Published. A reviewer queue surfaces what's waiting; only approved content can publish.
Editors, reviewers and admins each see what's relevant to them. Every publish and change is recorded in an immutable audit log.
Publishing is automatic and versioned. The moment approved content changes, the system rebuilds a fresh pack; the app picks it up on its next sync.
An editor builds an activity in the studio; a reviewer approves it. Content is validated against its schema on every save.
Publishing triggers a background job that compiles the module into a self-contained pack — content plus every referenced audio clip and image, each fingerprinted for integrity.
The new pack supersedes the old one with an incremented version, and is served from a CDN-backed endpoint the app reads.
The app fetches the catalogue, downloads new/changed packs, verifies them, and renders activities directly from on-device data.
Completions, scores and XP are written locally and synced to the backend when online — visible to LLF without ever blocking the teacher.
The codebase is built to be picked up by any engineer and kept honest by automation — not tribal knowledge.
Automated test suites cover the app's engine and the studio's logic; the production build is type-checked on every change.
The studio's live preview reuses the real app engine compiled to web — there is no second implementation to fall out of sync.
A continuous-integration gate and a commit-time guard fail the build if documentation drifts from the code.
A single source of truth. Each activity type is defined once as a JSON schema, validated by both the studio and the app. Add a new kind of activity by writing one schema — the authoring form and the contract follow automatically.
| Layer | Technology | Notes |
|---|---|---|
| Teacher app | Flutter (Android) | Offline storage on-device; one codebase, room to add iOS. |
| Content studio & API | Payload 3 + Next.js 15 (Node) | Containerised; runs content authoring, the publish pipeline and the learner API. |
| Database | PostgreSQL | Managed instance; migrations run on deploy. |
| Media & packs | S3-compatible object store + CDN | Audio, images and compiled packs, served fast and cached. |
| Live preview | Flutter-web bundle | The real engine, embedded in the studio for authoring preview. |
The studio ships as a single container with documented environment configuration; staging and production differ only in configuration, not code. An operational deployment guide accompanies the codebase.
The v0 vertical slice is complete and verified end to end — a teacher can sign up, learn, and play real authored Halbi content; an author can build content that reaches the app.
| MLE | Multilingual Education — teaching in the child's home language before bridging to the state language. |
| Pack | A self-contained, versioned bundle of a module's content plus its audio and images, downloaded by the app and run offline. |
| Activity / mechanic | A single learning interaction (e.g. a listening quiz). Its on-screen behaviour is the “mechanic”. |
| Schema | The single definition of an activity type's content — used to build the authoring form and to validate content on both sides. |
| Content studio | The web admin where LLF authors, reviews and publishes content. |