Production Restaurants
The web/backend system is in production for the order and distribution workflow.
CASE STUDY / 02
ONE Restaurants + Driver
ORDER & DELIVERY OPERATIONS
IN USE · SKLAVOUNOS MEAT
This presentation uses the ONE identity. The documented functions are used at Sklavounos Meat. Portfolio naming does not change the architecture or installed applications.
From order to delivery. The team organizes preparation and assigns the route in Restaurants. The driver sees their own stops in Driver and returns the delivery update.
CURRENT STATEIn use · Driver 1.3.2 source · Play status pending independent verification
00 / AT A GLANCE
The project at a glance.
PROBLEM
Order information must remain consistent from intake and preparation through assignment, routing and final delivery.SOLUTION
Restaurants organizes orders and distribution, while the separate Android Driver application executes assigned routes and returns delivery updates.IN USE BY
The operations team and approved drivers within an approved professional-customer order flow.OPERATES ACROSS
The Restaurants web/backend system and a separate Android Driver application.MY ROLE
Product design and UX, web/backend, Android, integrations and deployment.STATUS
Restaurants is in production. Driver source version 1.3.2 / versionCode 10 is verified, but no independent evidence of the current public Play listing or store-delivered version has been retained.01 / THE NEED
Delivery begins before the driver starts the route.
To close a professional order correctly, information must remain consistent from intake and preparation through assignment, routing and final delivery.
- The operations desk needs a clear view of orders, states and assignments.
- The driver needs only the assigned route, stops and permitted actions.
- Location is collected only during an active route and completion returns as a controlled Restaurants state.
02 / IN PRACTICE
What changed in practice.
A shared order-to-delivery flow keeps the operations desk and drivers aligned without merging the two products.
- The operations team organizes orders, states, priorities and assignments without parallel lists.
- Drivers see only their assigned stops and permitted actions, and explicitly start precise location only during an active route.
- Delivery completion returns to Restaurants so the status closes within the same operational trace.
03 / OPERATIONAL DEMO
From the operations desk to delivery.
The Restaurants render follows the structure of the real operations interface, while the Driver artworks show the mobile continuation. Every visual uses synthetic data only.
Tap to view full image
Tap to view full image
Public-safe renders based on the products’ current interfaces. No real customer, address, order or operational data is shown.
04 / THE FLOW
From order to closeout.
Restaurants and Driver remain separate products while sharing one strictly defined operational sequence.
- 01
01 / ORDER
Intake and review
Approved professional customers, products, pricing and a clear initial order state. - 02
02 / DESK
Preparation and assignment
The operations team organizes priorities, drivers and next steps without parallel lists. - 03
03 / ROUTE
Route execution
The driver sees assigned stops and explicitly starts precise location for the duration of the route. - 04
04 / CLOSE
Delivery and update
Completion returns to Restaurants so the status closes within the same operational trace.
ONE Orders is a third, customer-facing application and is not conflated with Restaurants or Driver in this case study.
05 / OPERATIONAL PROOF
A real workflow, not isolated screens.
The solution covers the daily transitions and access boundaries required by an actual delivery operation.
Driver 1.3.2 source
Source version 1.3.2 / versionCode 10 is verified. The latest direct Play evidence retained locally covers restricted Internal testing, not an independently verified public listing.
Controlled access
There is no open driver registration. Assignments, routes and permitted data remain role-scoped.
Privacy by operation
Precise location is explicitly started by the user only for an active route, with a persistent foreground-service notice.
06 / SCALE & EVIDENCE
Measured scope at the engineering checkpoint.
These are dated engineering records and isolated-staging results. They are not presented as a production SLA or a measure of business impact.
- Documented API routes
- 170Mapped routes at the verified local runtime/source checkpoint.
- Regression tests
- 1,096 / 1,096The isolated regression suite completed without a failure.
- Staging requests
- 48 / 48HTTP 200 with 12 concurrent workers, 0 errors and 0 responses in the 5xx range.
- Driver source version
- 1.3.2Android versionCode 10 at the verified source checkpoint.
EVIDENCE WINDOW30 July – 14 August 2026
07 / TODAY
In use, with clear next boundaries.
Restaurants is a production system. Driver source version 1.3.2 / versionCode 10 is verified, but the current public Play listing and store-delivered version are not. Until direct store evidence exists, this case study shows no Play badge or public download link.
NEXT EVIDENCE
- 01Verify the exact version currently distributed by Google Play.
- 02Keep stable release evidence for every Android promotion.
- 03Add the next public-safe visual for driver assignment and delivery closeout.
- 04Publish reliability measures without real customer data.
08 / CONTACT
Does an operational workflow need a clearer system?
Describe the current process, the tools you use and the point where time, information or control is being lost. The first conversation clarifies the need and the boundaries of a solution.