The problem
Meallift had restaurants signed up and no product. They needed to be taking real orders in ten weeks for an investor milestone, in one city, with ten couriers.
What I built
For customers — browse by cuisine or distance, a cart that survives app restarts, address book with map pin, live order tracking and a rating prompt that appears once and never nags.
For couriers — a dispatch panel with an accept/decline timer, turn-by-turn handoff to the phone's map app, and an earnings screen that matches the settlement report to the taka.
For the operator — zone-based pricing, a surge toggle for rain, and a daily settlement export that reconciles restaurant payouts, courier earnings and platform fee.
Decisions worth explaining
One city, one currency, one language. Every "we might need this later" was written down and deliberately not built. That list is why the deadline held.
Polling before sockets. Tracking started as a five-second poll, which was good enough for the pilot and took an afternoon. Sockets replaced it in week nine, once the rest of the product was real.
Money is integers. All amounts are stored in the smallest currency unit, as integers. Floating-point money is the one bug class I refuse to debug twice.
Results
- Live with ten couriers and 34 restaurants in week ten, hitting the milestone.
- Settlement disputes in the pilot: two, both data entry by the operator, none from the maths.
- The codebase handed over to the client's in-house team in month five, with a week of pairing.