Feature lists are written by sales teams. The features that matter are written by the person answering "where is my order" at 9pm. Here is the operational shortlist, in the order it starts hurting.
Order lifecycle
1. Explicit order states
Placed, accepted, preparing, ready, picked up, delivered, cancelled, refunded. Every state needs an owner and a timestamp. Vague states like "processing" hide the failures.
2. outlet accept/reject with a reason
Silence is the worst outcome. A rejection with a reason lets you refund fast and measure which outlets are unreliable.
3. Auto-reject timer
If an outlet does not respond in three minutes, escalate the alert, then reassign or cancel. Without this, the customer waits until they call.
4. Idempotent payments
Retried webhooks and double taps must not create two orders or two charges. This is invisible until it is a refund queue.
Dispatch
5. Zone-aware assignment
Riders should see jobs they can actually reach, not every job in the city.
6. Multi-order handling
At low volume, one order per trip is fine. At lunch peak, batching is the difference between six and nine deliveries per shift.
7. Offline resilience
Riders lose signal in lifts and basements. The app must queue status updates and sync, without duplicating them.
Money
8. delivery fee that is visible before payment
outlets tolerate delivery fee they can predict. They leave over reporting surprises.
9. Cash reconciliation
If you accept cash, the rider's shift must end with a number that matches the platform's number.
10. Refunds without support tickets
An admin override that refunds and restocks in one action saves hours a week.
Customer side
11. Reorder in two taps
The highest-leverage retention feature in food ordering, and the cheapest to build.
12. Honest delivery estimates
An accurate 40 minutes beats a false 20. The first builds trust; the second builds refunds.
13. Live status, not live GPS
Customers mostly want to know "preparing" vs "on the way". GPS is a nice extra, not a substitute for states.
14. Working search
Synonym-aware search for dish names and categories. If someone types "biryani" they should not get an empty screen because the item is filed under "Rice".
Decoration, not features
Animated splash screens, gamified loyalty wheels, in-app stories, AI recommendations before you have 500 orders. All of it can wait. None of it fixes a missed order.
When you evaluate a platform, ask for the order state diagram and the sales report before you ask for the colour picker.
Must-have vs nice-to-have
Feature lists are easy to inflate. The useful question is which features must work on day one, which can wait until you have order volume, and which are decoration. A missing refund flow costs more than a missing loyalty wheel.
| Stage | Features | Why |
|---|---|---|
| Launch | Menu, modifiers, cart, checkout, payments, order states, restaurant acceptance, rider assignment, tracking, refunds, admin reports | These are the order lifecycle |
| Month 2–3 | Coupons, loyalty, referrals, push notifications, scheduled orders, ratings | Retention and repeat orders |
| Later | Subscriptions, advanced analytics, multi-language, dark-store routing, AI recommendations | Optimisation after density |
| Decoration | Animated splash screens, gamified profiles, social feeds | Do not distract from ordering |
Customer app features
The customer app needs a fast menu, clear modifiers, a visible total before checkout, saved addresses, real delivery estimates and order tracking. Search and filters matter when the menu is large; for a 20-item restaurant, clear categories are enough. Payment methods should match the market: cards, wallets, UPI, QRIS, Fawry or cash on delivery.
Do not hide fees until the last step. Do not force account creation before the order. Do not let a payment failure empty the basket. Those three details affect conversion more than a new animation.
Restaurant and rider features
The restaurant app needs order acceptance, rejection with a reason, prep-time updates, item availability, menu editing, opening hours and a settlement view. The rider app needs a delivery queue, navigation, pickup and drop-off states, proof of delivery, cash collection and an earnings view. Both need to work on a mid-range Android phone with a weak connection.
Test the unhappy paths: restaurant rejects after the rider is assigned; rider cannot find the address; customer does not answer; item is out of stock; cash is short. A demo that only shows the happy path is not a delivery system.
Admin and reporting features
- Vendor onboarding, approval and commissions.
- Zones, delivery fees, minimum baskets and surge rules.
- Order search, refunds, cancellations and exceptions.
- Rider shifts, assignment and cash reconciliation.
- Settlement statements by vendor and period.
- Revenue, contribution, prep-time and late-order reports.
- Role-based access and an audit log.
MVP scope and launch sequence
Build or buy the smallest product that completes an order reliably. Launch with one zone, one payment method, one delivery model and a short menu. Add features only when the data shows a specific problem. A loyalty programme does not fix late deliveries; a better dispatch rule might.
If you buy a product licence, check which features are included and which are add-ons. The entry price may cover the core while the restaurant app, rider app, website or payment module is extra. Ask for an itemised feature list before you compare prices.