RoleCaller is a resilient, offline-first attendance and data platform built for the Malto community's tribal schools in the remote hills of Jharkhand, India. Geography, language barriers, and thin infrastructure have historically cut these schools off from consistent educational support — internet connectivity is a luxury and electricity is sporadic, so tools built for a connected world simply don't run there.
The project started from a personal visit, not a spec sheet. After spending time with the Malto community in 2023 and seeing the gaps firsthand, I realized that remembering what I'd seen was passive — it changed nothing on its own. A conversation with my father, gently pushing on what I actually planned to do about it, turned that awareness into RoleCaller: a tool that lets teachers capture attendance data on a device that already assumes the network doesn't exist, and treats connectivity as a bonus rather than a requirement.
Without a reliable way to record attendance, a student's absence becomes invisible. Kids in these communities often walk dangerous paths for hours to reach school, and miss days for family obligations, illness, or seasonal work — but with attendance scattered across paper registers, no one can see the pattern until a child has effectively dropped out. The instability is systemic, not a motivation problem, but there was no data trail to prove it, intervene early, or make the case for scholarships and continued schooling.
Community leaders were also explicit about what the tool could not become: 'We do not want to become the police.' Any system that turned attendance tracking into surveillance or an imposition of outside productivity norms would undermine the trust it depended on.
- Must run fully offline — teachers may go days without a signal, and the app cannot depend on a live connection for any core workflow.
- Targets low-end, sub-$100 Android devices with sporadic electricity — no heavy runtime or background overhead.
- Teachers may sync at most once a day — when a connection does appear, sync must be fast, safe, and never lose a day's work.
- Must support educator judgment, not enforce compliance — visibility for teachers and coordinators, not surveillance of students or staff.
Local-first SQLite with a custom "Pulse" sync engine
Each teacher's device treats its local Expo SQLite database as the single source of truth. A custom sync engine watches for a stable network connection, then pushes unsynced attendance records to a Node.js API backed by Postgres (Neon), and pulls fresh roster data back down. Pushed records aren't marked as synced locally until the server confirms a 200 OK, and the API upserts on conflict — so a crash mid-sync or a duplicated request never corrupts or loses data. Pulling roster updates does a 'smart wipe' that refreshes students and classes while strictly preserving any attendance a teacher hasn't synced yet.
Reason:
Teachers can't be blocked by the network, and a rare, unreliable connection window is the only chance to sync — so every push has to be atomic and every pull has to protect work already sitting on the device.
Tradeoff:
The push/pull protocol and smart-rehydration logic are more code to maintain than a naive "just sync everything" approach, but a naive approach risks silently dropping a day of attendance.
UUID v4 identifiers across every entity
Schools, classes, students, and attendance records all use UUID v4 primary keys, generated on-device at creation time rather than assigned by a central server.
Reason:
A device with no connectivity still needs to create valid, permanent records for new students or classes. UUIDs let it do that without ever asking a server for the next ID, and they slot into Postgres later without collisions.
Tradeoff:
UUIDs are larger and less human-readable than auto-incrementing integers, and require care in the schema and API layer to index and join efficiently.
Raw Node.js HTTP API with Drizzle ORM over Neon Postgres
The backend skips Express/NestJS in favor of a raw Node.js HTTP server with a shared connection pool, and uses Drizzle ORM to generate type-safe SQL with effectively zero runtime overhead.
Reason:
Sync bursts from many devices reconnecting at once need to be handled quickly on modest server hardware — minimizing framework overhead and cold starts matters more here than developer convenience.
Tradeoff:
Losing framework conveniences (routing, middleware, validation) means more boilerplate has to be written and maintained by hand.
Offline-capable authentication
Online logins authenticate against the API and cache a hashed "session snapshot" locally. If a teacher opens the app with no signal, RoleCaller falls back to verifying credentials against that cached, hashed record instead of failing closed.
Reason:
A teacher who hikes to a remote school needs to log in and keep working for days without ever seeing a signal tower — an app that requires a live login check would be unusable there.
Tradeoff:
Caching credentials on-device, even hashed, expands the local attack surface and requires careful handling compared to a stateless, always-online auth flow.
- Received board approval from FMPB in January 2026 to begin deployment across Malto community schools.
- Rollout is deliberately staged — starting with RCPSC and smaller schools before scaling to larger centers, to build trust before expanding.
- Built a working local-first architecture (SQLite edge, Postgres core, custom sync engine) that lets a teacher record attendance for days with zero connectivity and sync losslessly on reconnect.
- Designed alongside community leaders to keep the tool supportive rather than coercive, in line with explicit feedback against a "policing" framing.
- Awareness by itself changes nothing — the harder, more useful step is turning what you've seen into something concrete and usable.
- Respecting a community's values (no surveillance, no imposed productivity norms) is as much a design constraint as any technical one.
- Offline-first has to be a first-class assumption in every layer — IDs, auth, and sync all break if you bolt it on after the fact instead of designing for a missing network from the start.
- A cautious, staged rollout (small schools first) is often the right call for tools that affect real communities, even when the temptation is to scale immediately.