A three-sided food-delivery marketplace, end to end.
Give each audience its own front door and one shared API behind it. Diners, restaurants and riders authenticate through separate surfaces but operate on the same orders, described by a single OpenAPI spec. Rider payouts run through Stripe Connect, with transfers gated on onboarding eligibility.
Because the three audiences have genuinely different signup journeys. A diner needs to order in under a minute; a rider needs identity documents and a payout account before they can earn anything; a restaurant sits somewhere between.
Forcing all three through one flow makes it wrong for everyone. Separate surfaces over one API keeps the onboarding appropriate to each while the orders underneath stay shared.
Predictability in a system where three parties are all changing the same record. Placed, accepted, prepared, picked up, delivered: each transition is explicit, and invalid ones are impossible rather than merely unlikely.
Without it, concurrent updates from a restaurant and a rider produce states nobody designed. A state machine is the cheapest way to make that class of bug not exist.
Because paying someone who has not completed onboarding fails at the payment provider, and by then the order is delivered and the rider is expecting money.
Stripe Connect requires an onboarded account with verified details before transfers are permitted. Gating on eligibility checks that before promising anything, so the failure surfaces during onboarding rather than at payout.
Because the same event means different things. An accepted order is reassurance to a diner, a task to a restaurant, and an opportunity to a rider.
One generic notification table serving all three collapses into conditional logic everywhere. Dedicated models per audience keep the right message going to the right app without a growing pile of special cases.
It keeps three clients honest against one contract. With a diner app, a restaurant app and a rider app all consuming the same API, the spec is the shared reference that stops each drifting toward its own assumptions.
An admin console sits over the whole thing, so operations has one place to see orders, users and payouts rather than three.
A complete food-delivery backend with an OpenAPI spec, connecting diners, restaurants and riders under one admin console.
| Sides | Diners, restaurants, riders |
|---|---|
| Authentication | Three separate surfaces over one API |
| Orders | Explicit state machine from placed to delivered |
| Dispatch | Rider assignment with live tracking |
| Payments | Diner checkout plus Stripe Connect rider payouts |
| Payout control | Transfers gated on onboarding eligibility |
| Webhooks | Payout confirmation handling |
| Notifications | Dedicated model per audience |
| Contract | OpenAPI spec, single admin console |
Separate signup surfaces over a shared API. Diners need to order in under a minute, riders need identity documents and a payout account first, and restaurants sit in between. One flow for all three is wrong for everyone, but the orders underneath should stay shared.
Because three parties change the same record concurrently. Making each transition explicit means invalid states are impossible rather than merely unlikely, which removes an entire class of bug that otherwise appears only under load.
Riders are onboarded as connected accounts with verified details, and transfers are only permitted once that onboarding is complete. Checking eligibility before promising payment means the failure surfaces during onboarding rather than after a delivery is already done.
Better to model them per audience. The same event means different things to a diner, a restaurant and a rider, and one generic table serving all three turns into conditional logic spread everywhere. Dedicated models keep the right message going to the right app.
One account for perps, spot and copy-trading — and an AI that can trade for you.