OrderFlow Mobile — One App, Three Roles

Most restaurant software ships three separate apps: one for the owner, one for the kitchen screen, one for the rider. Three builds, three release cycles, three places for the data model to drift apart. This is one build.

The mobile companion to OrderFlow, my own ordering platform. A single React Native app with three route groups — owner, kitchen and driver. Who you are decides which group you land in after login, and the route tree is what enforces it, so a driver cannot reach an owner screen by guessing a URL.

Each role gets the app it actually needs rather than a shared dashboard with buttons greyed out:

Owner — live orders, menu, offers and the business settings, on the phone rather than at a desk.

Kitchen — the order queue and the state changes that move a ticket along. This is the screen that runs all evening, so it is built to survive a bad connection rather than assume a good one.

Driver — the assigned run, navigation hand-off, and location reporting that keeps working when the screen is off, through a background task rather than a foreground loop.

Expo with expo-router, so the route groups in the file tree are the access model instead of a separate permissions layer that can disagree with the navigation.

Server state goes through TanStack Query, which is what makes the live screens live: the kitchen queue and the owner's order list reconcile against the server instead of trusting whatever a navigation parameter carried over.

Push runs on Firebase Cloud Messaging with expo-notifications, because a kitchen that has to pull-to-refresh is a kitchen that misses orders. Sessions are held in expo-secure-store. Background location uses expo-location with expo-task-manager. Sentry reports crashes from real devices, which on Android is the only honest way to find out what broke.

Three apps mean three code paths for the same order. The moment the kitchen's idea of "ready" and the driver's idea of "picked up" live in different repositories, they drift, and the bug shows up as a customer waiting for food nobody is carrying. One build, one state machine, three doors into it.

This is my own product, not client work. The same shape — one build, role-aware routing, live server state — is what I would build for a business that has several kinds of staff touching the same operation.