Dev log · Mobile
How I Shipped the Orio OMS Flutter App to the Play Store
8 min read
While working as a Flutter developer at Orio Technologies, I helped build and ship the Order Management System (OMS) — a mobile app for tracking orders, managing inventory, and keeping field teams in sync. It’s live on Google Play today.
This post covers what we built, the technical decisions that mattered, and what I learned taking a business app from development to production release.
The problem we were solving
Retail and distribution teams needed a single place to create orders, check stock levels, and follow delivery status — without calling the warehouse or digging through spreadsheets. The app had to work on mid-range Android devices, handle spotty connectivity, and stay fast when order lists grew.
Stack and architecture
- Flutter for a single codebase across Android devices
- Firebase Authentication for secure sign-in
- Cloud Firestore for real-time order and inventory sync
- REST APIs for operations that needed server-side validation
- Firebase Cloud Messaging for order status push notifications
We kept the UI layer thin: screens consumed repository classes that abstracted whether data came from Firestore or the REST API. That made offline-friendly caching and later backend changes much easier.
Features that shaped the build
Real-time order tracking
Firestore listeners updated order status across devices within seconds. We mapped statuses (pending → confirmed → dispatched → delivered) to a clear timeline UI so non-technical users could scan progress at a glance.
Inventory handling
Stock levels were validated on the server before an order was confirmed. The app showed optimistic UI updates but rolled back gracefully when the API rejected an out-of-stock line item.
Role-based flows
Sales reps, supervisors, and admins saw different navigation stacks. We used route guards and feature flags stored per user document in Firestore.
Shipping to the Play Store
- App signing — Play App Signing with an upload key stored securely
- Privacy policy & data safety — documented Firebase data collection for the Play Console form
- Screenshots & listing — real device frames with short feature bullets
- Internal → closed → production — staged rollout with Orio’s ops team first
- ProGuard / R8 — release builds tested early; Firebase rules verified
What I’d do again (and what I’d change)
Do again: invest in repository pattern and typed models from day one. Define order state machines explicitly before building screens.
Change: add integration tests for the checkout flow earlier. We caught edge cases late that automation would have found sooner.