Skip to content
LARECloud Solutions

Engineering · 5 min

Designing for the worse network

If your software only works on good connectivity, it does not work. Notes from building for tier-three campuses.

Published
22 May 2026
Author
LARE Editorial
Reading time
5 min

Most Indian ed-tech is built and tested in Bengaluru, Hyderabad and Pune on fibre. It is then deployed to campuses where the connection drops several times an hour and upstream bandwidth is shared across a few hundred users.

The failure mode is not that the software is slow. It is that the software assumes the request will complete, and has no defined behaviour when it does not. A student submits an assignment, the request hangs, they refresh, and the work is gone.

Our rule is that any action a user takes must survive the network disappearing immediately afterwards. Submissions queue locally and sync when possible. Assessment answers are written to local storage on every change. The timer accounts for verified disconnection rather than punishing the candidate for it.

This is more work than it sounds, mostly because of conflict resolution — a student who submits offline on a phone and then opens the platform on a lab machine needs a defined outcome, not a race.

The compensation is that it also makes the software noticeably better on good connections, because you have been forced to stop treating the network as infallible. That was not the goal, but we will take it.

LARE Editorial · 22 May 2026

Let's build the bridge.

Whether you run a campus, a department, or a hiring pipeline, the first conversation is free and specific to your situation.

Talk to our team