Offline-first learning: designing for low-connectivity universities

The real default network

If you've ever tried to use a Western LMS on a 2G connection in rural Sierra Leone, on a packed minibus in Lagos, or in a hostel block on the wrong side of a campus in Mehsana, you know the experience. Pages half-load. Login times out. The submission you spent forty minutes writing gets eaten when you tap "Submit" and the connection drops mid-request. The student gives up. The teacher never sees the work.

The instinct of most ed-tech is to call this an edge case. It is not an edge case. For a meaningful chunk of the world's students, this is the normal case — the median experience, not the tail. Software that doesn't handle it isn't software for them.

So when we built Quad, we made a deliberate choice: treat offline as the primary case, not the edge case. Every screen has to load without a connection. Every action has to work without a connection. The network, when it shows up, is a nice-to-have that makes things sync.

Principle one: cache aggressively, expire deliberately

The most basic offline pattern is the read cache: when the app fetches something from the server, store a copy on the device. The next time the app needs that thing, return the cached copy first, then quietly refresh in the background if the network is available.

The tricky question isn't "how do you cache" — it's "when do you expire." Cache too aggressively and stale data starts showing up on students' phones. Cache too cautiously and the app reverts to needing a network for everything.

Our rule of thumb: course material almost never changes after publication — cache it for weeks. Grades change all the time — cache for minutes. Calendar events change occasionally — cache for hours. We tune these per data type, not per app. And we make the cache visible to the student: "Last synced: 2 hours ago" so they know if what they're seeing is fresh.

Principle two: queue writes, never lose them

Caching reads is easy. Queuing writes — the things a student does that need to go back to the server — is where most "offline" apps fall apart.

An assignment submission isn't a read. It's a write. It might include a large file. The student might press "Submit" and immediately walk out of network range. The student might also press "Submit" twice because the first tap didn't seem to do anything.

Our approach: every write is queued into a durable on-device outbox before any UI feedback. The submission shows as "Queued" immediately. A background worker tries to upload it whenever the network is available. Each queued action carries an idempotency key, so retrying never creates duplicates — even after the app is killed and restarted.

The result: a student can submit an assignment with no network, walk home for two hours, and the submission arrives safely on the server when their phone connects to Wi-Fi at home. They never have to wonder if it worked.

Principle three: never hide the network state

One mistake we made early on was hiding the connection state from the user. We thought: the app handles offline transparently, so why bother showing it?

The answer is: students need to know. If they're about to submit a 30-MB video and they're on 2G, they want to know to wait until they're on Wi-Fi. If a grade hasn't updated in two days, they want to know whether it's because the system hasn't given them a new one or because their phone hasn't been able to fetch one.

So we show network state in three places: a small icon in the top bar, a "Last synced" timestamp on data screens, and explicit "Queued / Sending / Sent" badges on every write action. The student is never guessing.

Principle four: bias toward small payloads

Even when the network is there, it's often slow and expensive. Mobile data costs real money for students in emerging markets — a percentage of a household budget that Western engineers rarely think about.

So we design endpoints that return the minimum data needed for each screen. We compress aggressively. We never download media unless the student opts in. We cache images at multiple resolutions so we can serve thumbnails on 2G and full-resolution only on Wi-Fi.

The hidden upside: the app loads faster on every network, not just slow ones.

The trade-offs

Offline-first isn't free. It costs engineering complexity. It requires careful schema design, durable storage, idempotency handling, and lots of edge-case testing. Bugs in offline mode are some of the hardest to reproduce and debug.

It also costs UX complexity. Offline state has to be communicated. Conflicts (the rare cases where the same record is edited in two places) have to be resolved. The student has to understand what's happening enough to trust the system.

For Western ed-tech serving Western students on Western networks, those costs probably aren't worth it. For everyone else, they are. The simple test: would your software still work for the student on the bus home? If not, design until it does.