Designing for Bad Connectivity as the Default Case

For a lot of engineering teams, offline support is a feature added near the end of a project. For Englo, it had to be a starting assumption — students studying for exams don't stop needing the app because their connection dropped.

The pattern we settled on: SQLite is the source of truth for anything the user needs to read — vocabulary, grammar rules, question banks — and the network is only involved for writes and background sync. On app launch, if cached data exists, it renders immediately; a sync check runs quietly afterward and updates the cache without blocking the UI thread or making the user wait on a spinner.

The verb conjugation module is a good example of why this matters in practice — it's a dense dataset of V1/V2/V3 forms with Bangla meanings and example sentences, exactly the kind of content a student wants to review on a commute with no signal. Treating it as offline-first from the schema design onward meant no retrofit was needed once real usage patterns showed people actually did that.

The trade-off is real: every write path needs a conflict strategy for when local and server state disagree. We keep that simple by making the server authoritative and the client cache disposable — it can always be rebuilt from a fresh sync, so we never had to build true two-way conflict resolution for a v1 product.