Building a delivery app: core functionality
A delivery app is never a single app — it is at least three linked interfaces: for the customer, the courier, and whoever assembles the order. Missing this at the budgeting stage is a common mistake.
Three sides of one system
The customer app: catalogue or menu, cart, address and time selection, payment, real-time order status. The courier app: available orders, route, status buttons, built-in navigation. The dispatcher or kitchen panel: order intake, courier assignment, timing control.
Building only the customer side and coordinating couriers over a Telegram chat works while volume is low. Manual coordination becomes the bottleneck before delivery capacity itself does.
Order tracking and notifications
Order status should update without user action: accepted, preparing, courier en route, courier nearby, delivered. Each status change is a push notification that cuts down support calls asking where the order is.
Live courier location on a map isn't mandatory but noticeably builds trust — technically it needs background location updates from the courier's phone at a frequency that doesn't drain the battery over a shift.
Payment and order handling
Online payment via Payme or Click cuts cash-on-delivery refusals and simplifies refunds. Plan separately for partial cancellations, out-of-stock substitutions, and how refunds work on an order already paid.
Integration with 1C or a kitchen management system removes manual order re-entry and keeps the menu synced with real stock — without it, sold-out items keep selling in the app until someone notices by hand.
Timeline and budget
A minimal version — customer app plus a simple order panel — takes 2.5-3 months and starts from 35,000,000 UZS. A full system with courier app, live map and inventory integration runs 60,000,000-90,000,000 UZS over 4-5 months.
Starting with the customer app and panel while coordinating couriers manually lets you validate demand before investing in a full logistics system.