Food and beverage platforms, built for the hour that actually decides everything.

Catalogue, menu and modifier modelling

This is the phase every team underestimates and the one that quietly decides whether the platform can scale past one vertical. A restaurant menu is not a product list. It is a tree of items, variants, modifier groups with minimum and maximum selection rules, availability windows, and per-store overrides on price and stock.

Grocery is a different shape again: tens of thousands of SKUs, weight-based items where the final price is not known until picking, and substitution rules the customer has to pre-approve. A platform that models a burger and a kilogram of tomatoes with the same schema will be rebuilt within a year.

The output is a catalogue model that survives both, plus the merchant-facing rules for what a store can override and what stays central.

Order lifecycle and the state machine

An order is a state machine with roughly a dozen states and a much larger number of illegal transitions. Placed, accepted, rejected, preparing, ready, assigned, picked up, delivered, cancelled by three different parties, refunded in part or in full. Every one of those transitions can arrive twice, out of order, or from a client that has been offline for four minutes.

The correctness question is not whether the happy path works. It is whether a merchant tablet that reconnects after a dropout can cancel an order that has already been picked up, and what the platform does when it tries. Idempotency keys on every write and a state machine that rejects illegal transitions outright are the difference between a support queue and a refund liability.

Partial fulfilment belongs here too. Grocery orders routinely ship short, and the money has to follow the goods that actually arrived.

Dispatch and courier assignment

Dispatch is the hardest engineering problem in the sector and the one most platforms get wrong by treating it as a nearest-courier lookup. The real problem is a scheduling one: you are assigning a limited courier pool against orders that are not yet ready, with prep times that are estimates, in a city where travel time depends on the hour.

Assigning too early strands a courier at a kitchen for eleven minutes and removes them from the pool. Assigning too late means the food sits. Batching two orders raises courier earnings per hour and lowers your cost per drop, but only if the second pickup is genuinely on the way, and a naive batcher will happily send a courier backwards.

This is also where courier supply meets economics. Incentives, surge and zone-level pricing are dispatch inputs, not a marketing feature bolted on afterwards.

Payments, splits and merchant payouts

One customer payment becomes four or five obligations: the merchant's share, your commission, the courier's earnings, the tip, and the tax that sits on top of some of those and not others. Getting the split right at order time is straightforward. Getting it right after a partial refund, a substituted item and a tip adjusted an hour later is where platforms leak money.

Merchant payouts run on a schedule, usually weekly, and every one of them is a statement a merchant will check line by line. If your ledger cannot reproduce a payout from the orders that made it up, you will spend the first month of every quarter reconciling by hand.

Tips deserve their own attention. In most markets a tip is legally the courier's, which means it cannot sit in your revenue and cannot be netted against a chargeback.

Peak load and promise-time accuracy

Food platforms do not have traffic, they have two spikes a day. Sizing against average load is how a launch goes down at seven on a Friday. Load testing here means replaying a realistic peak: concentrated in two postcodes, with merchant accept latency and courier supply modelled rather than assumed infinite.

Promise time is the number the customer judges you on, and it is the composition of four estimates that each have their own error. Quoting a tight window you miss is worse than quoting an honest one you hit, and the platform should be measuring its own accuracy per merchant and per hour from day one.

Merchant and courier onboarding at scale

Supply onboarding is an operational problem that presents as a software one. Getting the first fifty merchants live is a spreadsheet and a determined operations hire. Getting to five hundred is a self-serve flow with menu ingestion, bank verification, and a review queue for the ones that need a human.

Courier onboarding carries compliance weight that varies sharply by market: right-to-work checks, vehicle and insurance documents, and in some jurisdictions background screening with a defined re-check interval. Documents expire, and a platform that does not track expiry will eventually dispatch to an uninsured courier.

Launch city and day two

One city, one merchant cohort, one courier pool, then widen. Launching three cities at once triples the operational surface before you have learned what your promise times actually are, and every early problem in this sector is discovered through operations rather than monitoring.

Day two is where the sector differs from most: the first month generates a backlog of merchant disputes, courier earnings queries and refund edge cases, and the platform needs the tooling to answer them without engineering involvement. Sixty days of dedicated support, six months of priority bug resolution, twelve months of updates.