When the Wasey team first described what they wanted, it sounded simple: an app to order food. The moment we started mapping it out, the real shape showed up. A customer needs to browse and order. A vendor needs to manage a menu and accept those orders. A driver needs to pick them up and deliver. Those are three completely different jobs — and if any one of them falls out of sync, the whole thing feels broken.
So we didn't build one app. We built three, plus an admin panel to tie them together. The key decision early on was to treat each order as a single shared object living in one Firebase backend, rather than letting each app keep its own copy. That sounds obvious in hindsight, but it's the difference between a status update that's instant everywhere and a customer staring at 'preparing' while their food is already at the door.
The customer app is the friendly face of the platform — browse vendors, build an order, pay, then watch it move through each stage. We kept that flow deliberately short. Food ordering is an impatient moment, and every extra tap is a chance to lose the sale.
The driver app is a working tool, not a storefront. Drivers see incoming jobs, accept them, and get to the pickup and drop-off without fuss. We designed it for quick, on-the-move use, because that's exactly how it gets used.
The vendor app and admin panel are where the business actually runs. Vendors manage their menu and handle the orders coming in; the admin team sees the whole operation — every vendor, every driver, every order — from one place. That central view is what makes a marketplace feel like a marketplace instead of a pile of disconnected apps.
The hardest part was never any single screen — it was the choreography between them. An order that's accepted, prepared, picked up and delivered touches all three apps, and each transition has to land everywhere at once. We leaned on Flutter and a real-time Firebase backend so a change on one device ripples out immediately, and spent most of our testing time on the seams rather than the surfaces.
What shipped is a connected ecosystem: customers order, vendors operate, drivers deliver, and admins keep an eye on all of it. If you're building something with multiple sides like this — a marketplace, a delivery network, a booking platform — the lesson from Wasey is to design the shared data first and the screens second.
Want something like this?
This is a real project we designed and built end to end at Bloom Cypher. See the full breakdown — scope, stack and outcome — on the case study page.