Every delivery platform demo looks good with twelve menu items and one test rider. The differences show up on a Friday night with 60 live orders, two vendors closed early and a rider who went offline mid-delivery. These are the questions that predict which product survives that.
1. Who owns the code and the data?
Ask directly: if I stop paying, does the storefront stay up? If the answer involves a licence check, a hosted tenant or an export fee, you are renting. Renting is fine for a test; it is expensive for a business.
2. What happens when a vendor misses an order?
There must be an escalation path: sound alert, repeat notification, auto-reject after a timer, and an admin override that reassigns or refunds without a support ticket. "The vendor will see it in the panel" is not a design.
3. How does dispatch actually work?
Three models: manual assignment, a broadcast queue where riders accept, and algorithmic assignment. Most platforms need the queue. Ask whether a rider can hold more than one order, what happens when nobody accepts, and whether the customer sees the rider's live position or just a status label.
4. How are vendor settlements calculated?
Commission percentage, per-order fee, delivery fee ownership, refunds, promotions funded by the platform versus the vendor — each one changes the payout. If the platform cannot produce a settlement report the vendor can reconcile against their own records, you will spend your month on disputes.
5. Are delivery zones real?
Radius circles are fine for a pilot. Real cities need polygons around neighbourhoods, separate fees per zone, minimum baskets and the ability to switch a zone off during a storm. Test drawing one before you buy.
6. What works offline?
Riders lose signal in lifts and basements. The rider app must survive a dropped connection and sync when it returns. Vendors on bad Wi-Fi need an order queue that does not duplicate tickets on retry.
7. Which payments are supported?
Card, wallet and cash on delivery is the baseline in most markets. Check that the gateway is available in your country and that the merchant account is in your name — not the vendor's.
8. Can you rebrand the apps?
Your logo, your package name, your store listing. If the app is published under someone else's developer account, you do not control your own product page, and a policy dispute can remove your app overnight.
9. Who fixes it in month three?
Ask what the support window is, what it covers, and what happens after. "30 days of bug fixes" is normal; "no access to the code afterwards" is not.
Scoring it honestly
Give each question a score out of three and refuse to be swayed by the demo's animation quality. A platform that scores well on ownership, dispatch and settlements but looks plain will out-earn a beautiful app that cannot reconcile a payout.
The 30-minute demo script
Do not let the vendor drive the demo. Ask them to run your script:
- Place an order with two modifiers and a discount.
- Reject it as the restaurant after the rider is assigned; show what the customer sees.
- Change a delivery zone and confirm the fee changes at checkout.
- Run a partial refund and show the vendor statement.
- Pause one item and confirm the rest of the menu stays live.
- Export orders and settlements to CSV.
- Show the rider app on a mid-range Android phone.
If the vendor cannot run the script live, ask for a recorded walkthrough. A pre-recorded happy-path demo is not enough.
A weighted scorecard
| Criterion | Weight | What good looks like |
|---|---|---|
| Order lifecycle | 20% | Reject, refund, reassign and cancel all work |
| Dispatch | 15% | Prep-time aware, manual override, rider states |
| Vendor settlements | 15% | Order-level statement with reason codes |
| Payments | 15% | Local methods, refunds, fallback |
| Ownership | 15% | Source code, export, licence clarity |
| Support | 10% | Defined window, response time, who fixes bugs |
| Total cost | 10% | Three-year cost including add-ons |
Contract terms to check
- Number of production installations and domains.
- Whether client work, resale or SaaS hosting is allowed.
- Source-code access and update policy.
- Support window, response times and exclusions.
- Data ownership and export format.
- Refund policy and what happens if the vendor stops trading.
Red flags in a sales demo
Beware of a demo that only shows the admin dashboard, a feature list with no live order, or a “we can integrate anything” answer with no example. Ask who owns the code, who hosts it and who fixes a payment bug on a Friday night. If the answer changes between sales calls, get it in writing.
The best software is not the one with the longest feature list. It is the one whose unhappy paths your team can operate without a developer on call.