WiFi in Singapore hawker centres is unreliable. Here's how we built Lunchbox to handle offline-first transactions with automatic sync.
The Challenge
A hawker stall doing 200+ transactions per day can't afford downtime when the WiFi drops. Traditional cloud POS systems freeze. Customers leave. The lunch rush doesn't wait for your router to reboot.
We learned this the hard way during early pilot testing at a hawker centre in Toa Payoh. The merchant lost 15 minutes of transactions during peak hour because the shared WiFi went down. That's roughly $300 in lost revenue — in one lunch service.
Our Approach
We rebuilt the core transaction engine to be offline-first:
- Local-first data storage with IndexedDB — every transaction is written locally before any network call
- Background sync when connectivity returns — uses the Background Sync API with exponential backoff
- Conflict resolution for multi-device setups — timestamp-based last-write-wins with manual override for edge cases
- Payment fallback modes — PayNow QR works offline via static QR codes; NETS requires connectivity but we queue the confirmation
The Key Insight
Don't treat offline as an error state. Treat it as the default state, and online sync as a bonus.
This changes everything about your architecture. Instead of "fetch from server, display to user," it becomes "read from local store, display to user, sync in background." The UX is faster even when you have great WiFi, because you're never waiting on a network round-trip for the critical path.
Results
We've had merchants run full lunch rushes on zero WiFi without a single lost transaction. The sync catches up within seconds once connectivity returns, and the dashboard shows real-time data as if nothing happened.
If you're building for markets with unreliable connectivity, the offline-first mindset changes everything. The investment in local-first architecture pays for itself in reliability alone.
Check out what we're building at lunchbox.asia.
Top comments (0)