Custom Online Ordering System for Restaurants

Branded ordering experience on mobile web, desktop, and native iOS and Android apps. The decision between a white-label web ordering page and a native iOS/Android app depends on your customer behaviour: web ordering converts well for search-driven customers who arrive via Google; native apps serve repeat customers better because of home screen presence and push notification access via APNs (Apple Push Notification service) and FCM (Firebase Cloud Messaging). Most restaurant groups build the web ordering page first and add native apps once direct order volume justifies the additional build cost.

Menu displayed with item photography, descriptions, allergen information, and dietary filters. EU FIR 1169/2011 requires allergen disclosure for the 14 regulated allergens (gluten, crustaceans, eggs, fish, peanuts, soybeans, milk, nuts, celery, mustard, sesame, sulphites, lupin, molluscs) on food prepared and sold on premises -- the system stores allergen flags per menu item and surfaces them in the ordering interface and in a downloadable allergen matrix. Dietary filters (vegan, vegetarian, gluten-free, dairy-free) are derived from ingredient flags and displayed at the menu level so customers can filter before browsing rather than reading individual item descriptions. Delivery and collection toggle so customers choose at the start of the order and the flow adapts accordingly. Checkout with card payment via Stripe (saved card for returning customers), Apple Pay, and Google Pay. Order-ahead scheduling lets customers select a future time slot for collection or delivery, with slot availability controlled by kitchen capacity settings. Order confirmation delivered via push notification for app orders and by SMS/email for web orders.

Item availability by time of day and by location so breakfast items disappear at 11am and location-specific specials appear automatically. Modifier groups with min and max selection rules: choose one sauce, choose up to three toppings, choose a required base. Combo meal management where a combo contains a main, a side, and a drink with their own modifier trees. Item 86 -- mark an item as unavailable for the rest of service from the manager tablet when stock runs out, with automatic restoration for the next service period. Menu change workflow where the kitchen team or manager marks items unavailable without needing system access. The menu engine that keeps what the customer sees aligned with what the kitchen can deliver.

Real-time menu sync with the POS is a critical requirement for any direct ordering system: if the POS is the system of record for prices and item availability, the ordering system must stay in sync with it rather than maintaining a separate copy that drifts. Sync is implemented via webhook from the POS on item or price changes -- Toast, Square, and Oracle MICROS all provide webhook or API endpoints for menu data. Toast webhooks publish menu changes within seconds; Square uses the Catalog API with a webhook subscription; Oracle MICROS integration uses the Simphony Cloud REST API. The sync is bidirectional for item 86 events: when an item is 86'd at the POS, the change propagates to the online menu within 60 seconds so online customers cannot order an item the kitchen has already run out of. ETA promise calculation uses historical prep time data by item category and current kitchen load to set an accurate collection or delivery time at the moment of checkout -- reducing the false-promise problem that occurs when restaurants set a fixed 20-minute ETA regardless of current kitchen state. For overflow demand beyond direct channel capacity, the DoorDash Drive API and Uber Eats Marketplace API provide white-label delivery fulfilment without the consumer-facing commission structure.

Orders routed to kitchen display screens by station immediately on receipt -- no paper ticket printing, no verbal relay. Configurable routing rules: cold starters to the cold section, grilled items to the grill, desserts to the pastry section. Routing rules are configured per item category and modifier, so a burger with a hot sauce modifier routes to the grill station and the dessert items on the same order route to the pastry section simultaneously. Timing display showing how long each order has been waiting so the team manages pace rather than reacting to complaints.

KDS order routing is built on the same webhook infrastructure as the POS sync: orders from the direct channel fire a webhook to the KDS integration layer, which applies the routing rules and publishes the order to the correct station screen within 2-3 seconds of the customer confirming payment. Orders from third-party platforms (received via the Uber Eats or DoorDash integration) follow the same path -- one KDS view covering all order sources. Order consolidation for multi-item orders: all items for a table or delivery order displayed together so the expediter can hold and check before dispatch. Bump screen confirmation when a station completes their items so the expediter knows what is ready. ETA calculation feeds the KDS timing view: items are highlighted in amber at 70% of the ETA window and red at 100%, prompting the station to prioritise. Push notification for order status updates -- "your order is being prepared," "your order is ready for collection" -- are sent via APNs for iOS app users and FCM for Android users, reducing the inbound calls from customers asking about their order status.

Integration with Uber Eats, DoorDash, and Deliveroo so orders from those platforms arrive in the same kitchen workflow as direct orders -- one screen, one process. Menu sync keeping item names, prices, and availability consistent between your direct system and third-party menus. Order status updates sent back to the platform so the delivery driver's app shows accurate preparation and ready times. Commission reporting showing what is paid to each platform per month against direct order revenue so the true cost of each channel is visible. The integration that lets you run third-party platforms without running a separate system for them.

Third-party integration uses each platform's official API: the DoorDash Drive API for white-label delivery fulfilment (where DoorDash drivers handle delivery without the consumer marketplace commission), the Uber Eats Marketplace API for orders placed on the Uber Eats consumer app, and the Deliveroo Restaurant API for Deliveroo orders. The integration subscribes to the platform's order webhook -- new order events are received, mapped to the internal order schema, and forwarded to the KDS in the same format as direct orders. Order status updates (accepted, in preparation, ready, picked up) are sent back to the platform via the API so the driver's app reflects the current state accurately. This eliminates the second tablet on the counter showing third-party orders separately -- operations teams find managing two order streams on separate hardware more disruptive than the original problem. Menu sync ensures prices and 86'd items are consistent across all channels: a price change in the direct system propagates to third-party menus via the platform APIs within the platform's update window (typically minutes for Uber Eats and DoorDash, longer for some platforms with manual review requirements).

Points earning on every direct order -- a specific reason for customers to order direct rather than through a commission-charging platform. Discount codes and promotional pricing applied at checkout with single-use or multi-use rules. Birthday offer automation sending a discount code timed to arrive before a customer's birthday. Triggered campaigns based on order behaviour: a reactivation offer to customers who haven't ordered in 30 days. Integration with email marketing platforms so customer order data drives segmentation without manual export. The loyalty layer that gives customers a reason to choose your direct channel over the platform they already have installed.

Loyalty points are earned on direct orders and redeemed at checkout -- the earn rate (e.g., 1 point per $1 spent) and redemption rate (e.g., 100 points equals $1 off) are configured in the admin interface and can be updated without a code release. QR code scan at in-store ordering allows customers to earn points when ordering at the counter rather than online, linking in-store and online order history in the same customer record. Points balance and transaction history are visible in the customer's app or account page. For customers without the app, QR code scan on receipt links the order to their account post-purchase. The Stripe payment integration handles loyalty redemption as a partial payment: the discount is applied as a line item credit before the card charge is calculated, so the card is charged only for the net amount. For email marketing, the integration with Klaviyo, Mailchimp, or your preferred email platform sends order event data (order placed, order value, items ordered, loyalty points balance) via webhook or API so customer segments are built from actual purchase behaviour rather than manual lists.

Customer selects collection from a specific location or enters a delivery address and the system routes the order to the nearest kitchen covering that postcode. Delivery zone configuration per location: draw the zone on a map, set minimum order value, set delivery fee by zone tier. Collection time slots by location so customers pick a time that matches kitchen capacity. Order sent to the correct kitchen POS or KDS automatically with no manual routing step. Consolidated management view showing orders across all locations for the operations manager. The routing logic that means the customer always sees the right menu, the right delivery time, and the right price for their location.

Multi-location management separates configuration by location while providing a consolidated operational view. Each location has its own menu (with shared items inherited from a master menu and location-specific overrides), its own delivery zones, its own KDS routing rules, and its own time slot availability settings. When a customer enters a delivery address, the system queries which location's delivery polygon covers that address -- using a polygon-in-point geospatial check against the zones defined for each location -- and presents the menu and ETA for that location. If multiple locations cover the address, the nearest by road distance is selected or the customer is given a choice. Future time slot management allows each location to configure capacity slots: maximum orders per 15-minute window, advance booking horizon (e.g., up to 2 days ahead), and blackout periods for closed days. Slots fill as orders are placed and are hidden from the ordering interface when full, preventing the kitchen from receiving more orders than it can fulfil in a given window. The operations manager dashboard shows live order count, average prep time, and order value by location in a single view -- the cross-location visibility that makes managing a restaurant group operationally tractable.