Every development company says it builds “Uber Eats for your city”. Very few have shipped a dispatch system, reconciled cash-on-delivery, published three apps to two stores and supported a Friday-night peak. The proposal looks similar; the delivery risk is not.
This checklist is for buyers comparing an agency build with a product licence. It is not an argument against custom software. It is an argument for verifying the team before you commit six months and a five-figure budget.
1. Ask for delivery-specific proof
Look for a live platform, not a portfolio mockup. Ask for the customer app, restaurant app, rider app and admin in the same deployment. Then ask what happened after launch: order volume, peak handling, refunds, rider utilisation and the first major bug.
A team that has only built ecommerce apps will underestimate dispatch. A team that has built a food ordering website but never managed riders will underestimate the operational edge cases.
2. Separate the demo from the architecture
Ask for a walkthrough of the order state machine: placed, accepted, preparing, ready, assigned, picked up, delivered, refunded, cancelled. Then ask what happens when the restaurant rejects after the rider is assigned, or when payment succeeds but the order fails to create.
These are the flows that decide whether the platform survives real operations. If the answer is “we will handle it in development”, you are funding discovery, not delivery.
| Area | Question | Red flag |
|---|---|---|
| Experience | Show a live multi-vendor deployment | Only screenshots or a single-restaurant site |
| Scope | Which apps and admin are included? | “Apps sold separately” discovered later |
| Ownership | Who owns the repository and IP? | Vague answers or vendor-held code |
| Payments | Which gateways are live in our country? | “We can integrate anything” with no evidence |
| Security | How are secrets, access and backups handled? | No written policy |
| Handover | What documentation and training are included? | No runbook or credentials handover |
| Support | What happens in month four? | No warranty or retainer defined |
3. Price the same scope across options
Ask every vendor to price the same list: customer app, restaurant app, rider app, admin, website, payments, SMS, maps, zones, commissions, settlements, analytics, app-store publishing, training and 30 days of support. Then compare. A low quote that excludes three apps is not a low quote.
Also compare the cost of change. Custom code can do anything, but every change has a price and a regression risk. A product licence limits some changes but makes the baseline cheaper to maintain.
4. Test communication before signing
Send a written question about a tricky flow and see who answers. If the sales team cannot bring an engineer into the conversation before the contract, they will be hard to reach after it. Ask who will be the technical lead and how often you will see a working build.
Weekly demos beat monthly status reports. A team that can show a working order flow every week is much less likely to surprise you at launch.
5. Protect the handover
The contract should state who owns the code, database, domains, app-store accounts, payment accounts and customer data. It should require a repository handover, environment documentation, credentials and a final knowledge-transfer session. If the agency disappears, you need to be able to hire another one.
Build or buy?
If your delivery model is standard, a product licence plus a small implementation budget is usually the fastest path. If the operation itself is the differentiator — proprietary routing, unusual categories, deep hardware integration — a custom build can be justified. Most first launches are not that. They are a menu, a zone, a rider fleet and a payment gateway, all of which a product already handles.
Compare the four buying models, see the $299 licence, or read India development costs.