Make SQLite the interaction layer
Order creation, editing, customer work, and other day-to-day actions commit locally first through Drift. The network becomes a synchronization concern rather than a prerequisite for using the app.
Case study
IndependentProduction
Independent Build
Orderly
A public iOS and Android order tracker and offline-first business management app for small businesses, backed by sync, licensing, analytics, receipts, and admin tooling.
My role
Product engineer with end-to-end ownership across mobile architecture, backend APIs, admin tooling, store entitlements, and launch operations.
3languages shipped
Offline-firstlocal data and queued sync model
iOS + Androidpublic mobile releases
01 · Context
The problem was not another screen. It was making the whole workflow hold together.
Orderly was built for small businesses where the real order system is often spread across chats, notes, memory, payment messages, and whatever connection happens to be available at the time.
The mobile app needed to stay fast and writable offline, then become a real product around that core: cloud backup and sync, customers, payments, receipts, analytics, multilingual UI, store entitlements, support tooling, and admin operations.
02 · Constraints
What shaped the engineering choices.
- 01
Creating or editing an order cannot depend on network availability, so the local database has to be the immediate interaction layer rather than a cache behind a remote API.
- 02
A remote refresh must not silently overwrite local rows that are still waiting to sync. Unsynced business data needs an explicit preservation strategy.
- 03
The product has to work across iOS and Android, three languages, store purchase/restore flows, and the backend/admin systems needed to operate a paid product.
03 · Ownership
Built end to end, with the product and engineering decisions connected.
Designed and built the Flutter mobile product around Drift/SQLite persistence, business workflows, local writes, queued synchronization, merge refresh, and dirty-row preservation.
Implemented the wider product system: Firebase services, backend APIs, Firebase Admin SDK tooling, JWT-protected admin routes, pricing and transaction controls, support operations, and entitlement handling.
Owned multilingual delivery, store purchase and restore flows, release preparation, public App Store and Google Play launches, and the operational work required to keep the product sellable after launch.
04 · Engineering decisions
The choices that made the product dependable.
Queue sync instead of blocking writes
Local changes can be marked for synchronization and retried when connectivity returns. That keeps the business workflow responsive and makes network failure visible to the sync layer rather than every screen.
Merge refreshes around dirty local rows
Remote data is merged with the local store instead of replacing it wholesale. Rows with unsynced local changes are preserved so a refresh cannot erase work that has not reached the backend yet.
Treat product operations as part of the system
Lifetime Pro, store purchase restoration, pricing, transaction tooling, support, and admin controls were designed alongside the app because a paid mobile product is more than its client-side feature list.
05 · Hard parts
The work that mattered after the happy path was done.
Offline and cloud state can disagree
The hard problem is not detecting whether a device is online. It is deciding which state is authoritative when local business edits, queued writes, and remote records overlap. Dirty-row preservation and merge refresh make that conflict explicit.
Three languages inside operational UI
English, Sinhala, and Tamil support touches labels, receipts, navigation density, validation, and the small pieces of copy that appear throughout a busy workflow. It has to work as product behavior, not just translated strings.
Entitlements across two stores and a backend
A lifetime unlock still requires purchase, restore, account, and admin paths to agree on entitlement state. The mobile stores and backend tooling need a clear boundary so support cases are recoverable.
06 · Outcome
What the work left behind.
Orderly is live on both the App Store and Google Play with offline-first order management and cloud backup/sync.
The mobile app ships in English, Sinhala, and Tamil.
The product includes a one-time Pro purchase/restore flow plus the backend and admin tooling needed to operate pricing, entitlements, transactions, and support.
07 · Product walkthrough
The interface, not just the bullet points.
6 published screenshots from the product. Open any frame to inspect it at full size.
Stack
The tools behind the decisions.
FlutterDrift / SQLiteFirebaseFirebase Admin SDKJWT authApp Store / Google Play billing