Consumer / Marketplace
Three connected applications — customer, delivery partner and restaurant/admin — sharing one order lifecycle and API.
A food delivery product is not one application. A customer placing an order, a restaurant preparing it and a delivery partner collecting it are three different users with three different interfaces — all reading and writing the same order, at the same time, from different places.
Treat the order as the single shared entity and give each role its own client over a common API. The order moves through an explicit lifecycle; each role may trigger only the transitions that belong to it; every client reflects state changes rather than deciding state locally.
A simplified, public-safe view of how the pieces fit together.
Clients
Three role-specific interfaces
API
Authentication, validation, role-specific endpoints
Domain
Placed → Accepted → Preparing → Picked up → Delivered
Data
Orders, items, restaurants, partners, status history
When each app tracks status locally, the three disagree the moment a network call fails. Keeping status transitions server-side and having clients render what the server reports removed a whole class of "the restaurant says preparing, the customer says placed" bugs.
Phones lose connectivity mid-request. Retries then risk creating a second order. Making submissions idempotent — the same request identifier producing the same result — makes a retry safe.
Three parties all want the current state at once. Push notifications for state changes plus a lightweight refresh on screen focus kept the apps current without constant polling.
Each role worked in an interface built for it, while the order stayed consistent across all three.
Keep reading
Workflow-driven clinical application with role-based access, dashboards and enterprise integrations.
Record management, multi-criteria filtering, reporting and role-scoped dashboards for internal business teams.