List the stop, not the truck.
- Service design
- Product design
- Coded prototypes
- Business model
Problem
Delivery apps list a food truck like a restaurant that never moves. You walk to the pin and the truck isn’t there, or the kitchen can’t take one more order.
Solution
A “stop”: a set place and time that only goes live once the crew checks in, with pickup slots the kitchen can actually keep. What the crew does, customers see.
- 2Working prototypes, customer and crew
- 3Truck crews I talked to in person
- 4Checks a pilot passes before anyone scales
The problem
A listing built for restaurants can’t tell the truth about a truck.
Every listing I looked at shows distance, menu and an ETA. All three assume the kitchen stays put. A truck can be late, parked at the other gate, or out of the dish you walked over for, and the listing has no way to say so. So the job wasn’t helping people find trucks. It was making the app honest about them.
Four changes, each leaning on the one before.
- List the stop, not the truckA place, a time window and a status, instead of a pin that wanders.
- Check in before it shows upA stop only appears once the crew says they’ve arrived.
- Pickup slots the kitchen can keepSlots follow how fast the kitchen really cooks, not a hopeful ETA.
- When something changes, say soWhat the crew does updates the customer’s order straight away.
Try it
Customer
A stop you can plan lunch around.
- Find a confirmed stop
- Reserve a capacity-backed slot
- Collect or recover in one order
Ready for pickup
Crew marked the order ready at 12:42 PM.
Collect at Gate 3 →
With three crews
Parking, fees and demand worried the crews more than the app did.
The whole idea depends on crews checking in on time and changing slots in the middle of a rush. I wasn’t sure that was realistic, so I went to three food trucks and asked them. They said they could do all of it: check in when they arrive, set pickup slots, change them mid-rush, and tell customers when something changes.
What worries them has nothing to do with the app, so that’s what a pilot needs to test.
- Parking and permitsWhere a truck can stop isn’t up to the crew.
- Platform feesThe commission comes out of their margin.
- Unsteady demandIt’s hard to know how much to prep.
Should anyone build this?
Should a delivery platform invest?
Maybe, but only if verified stops bring in new orders after paying for the site, support and running costs. Strong truck sales alone can hide an operator losing money, the platform quietly paying for it, or people just ordering from the truck instead of a restaurant nearby.
The pilot passes four checks before anyone scales it.
- Check the siteCan the truck reliably arrive and hand food over there?
- Prove the stopDemand, queues, waste and what the operator takes home.
- Keep the money apartWhat the operator earns, and what the platform earns.
- DecideStop, try again, extend or invest.
My recommendation: run a small pilot with scheduled stops. Grow only if the stops stay reliable and both sides make money.
A pilot worth running. The business isn’t proven yet.
I started this on my own, and it isn’t connected to Zomato. It began with desk research I read on 30 Aug 2026: app listings, FSSAI and government scheme pages, competitor apps and published studies. Then I went and talked to three truck crews. That’s only three, so I’m not calling it proof. Every number in the prototype is made up to show how it behaves, and the photos are AI-generated.
What I’d do differently
Talk to the crews before drawing anything.
I drew the crew’s side first and only went to the trucks afterwards. Luckily it held up, but they could have sent me straight back to the start. If I’d heard about parking, fees and demand earlier, I’d have planned the pilot around them from day one.
What would prove me wrong
Trucks sell well, and the platform gains nothing.
If people just order from the truck instead of a restaurant nearby, the platform is paying for a shift, not for growth. The pilot’s money check is there to catch exactly that.
