04 · Product Engineering
Offline-First Study Platform
The client owned something genuinely valuable and completely unusable: a classical Arabic dictionary of more than eight thousand entries, locked in a static database file. Learners wanted to study from it — on a phone, on a commute, without a signal. Getting there meant building two applications off one data core and making a multi-megabyte corpus feel instant on a mid-range Android device.
- Client
- An independent language-learning publisher
- Sector
- Education / Consumer Product
- Engagement
- Product build and store release
- Year
- 2026
8,384
Dictionary entries indexed
20
Store releases shipped
7.6 MB
Downloaded once, then never again
Seconds → instant
Search latency after migration
One data core, two applications
The web application runs on React 19 and Vite. The mobile application is built with Expo and React Native and ships to the store through managed builds. They share the dictionary schema, the study-scheduling logic and the sync contract, so a definition corrected once is corrected everywhere.
Twenty versioned builds went out over the life of the engagement. Release was part of the work, not a phase that happened to someone else afterwards.
The performance rewrite
The first web implementation loaded the dictionary through a WebAssembly SQLite build in the browser. It worked, and it was slow: a heavy initial parse, a large resident memory footprint, and search that made users wait.
We migrated the storage layer to IndexedDB with indexes designed around the queries the app actually makes — prefix lookup, root lookup, category browse. The public API of the data service stayed identical, so the rest of the application did not change. A one-time background migration converts every entry on first launch behind a progress screen, and from then on the dictionary is local. Search became instant, and the 7.6 MB payload is fetched exactly once in the app’s lifetime.
Scheduling that respects the learner
Review scheduling uses FSRS, a modern spaced-repetition algorithm, rather than the fixed intervals most study apps still ship. Cards surface when the learner is about to forget them instead of on a calendar that ignores how they are actually doing.
Progress, study lists and statistics sync through Supabase, so a session started on a laptop continues on a phone.
Offline is the default, not the fallback
Every core action — search, browse, review, record progress — completes with the network off. Sync is a background reconciliation rather than a precondition for using the product.
That constraint shaped the whole architecture, and it is the reason the app is usable on a commute, in a classroom with bad reception, or on a prepaid data plan.
A dormant reference work is now a product people use daily, on two platforms, with progress that follows them between devices.
The client ships updates themselves: content changes flow through a conversion script and out to both applications without an engineering engagement.
Built with
Next case study
Community Operations Platform
Two aging Web Forms applications, rebuilt as one portal that a volunteer committee can actually run.