Inside a Bayon product · Thunderlist
Thunderlist: the real test came when the connection disappeared
An owned-product engineering case study in making a task app useful beyond the online demo.
What the demo couldn’t tell us
A task app needs to remain useful when the connection drops. Thunderlist’s offline startup work exposed a distinction: reaching an offline fallback page is different from opening a workspace with a previously cached task.
Repair the behavior beneath the screen
We repaired the workspace bootstrap path so it did not start online preparation while offline. The wider task-detail recovery contract uses cached data when available and gives a clear reconnect path when it is not. Cached subtask data is kept separate from server-confirmed counter reconciliation.
Verify the actual operating condition
After reconnecting and priming the app, a cold offline launch on an Android emulator displayed the cached task and offline indicator without the workspace-bootstrap warning.
This verified one cached-task scenario in one authenticated workspace on one Android emulator. The first unprimed launch showed the offline fallback. It does not establish every offline flow, physical-device behavior, iOS behavior, or universal launch readiness.
This is Bayon’s own product, not a client engagement. It demonstrates a specific engineering method; it makes no claim about how the original app was authored.
Explore Thunderlist
