Zapp.
On-demand delivery in a dense city is a dispatch problem with a storefront.
- Client
- Zapp
- Sector
- Quick commerce
- Scope
- App + web + admin
- Stack
- React Native, Node.js, PostgreSQL
A quick commerce build across app, web and admin, covering ordering, rider dispatch and live tracking at metropolitan scale.
What made it hard.
Stock accuracy per store decides whether the delivery promise is deliverable or a cancellation.
Rider supply
Demand spikes in twenty-minute windows. Supply has to be forecast, not reacted to.
Slot honesty
Showing a delivery window you cannot meet costs more than showing a longer one.
Unit economics
Every extra minute and every failed drop is measurable margin.
What we shipped.
A quick commerce build across app, web and admin, covering ordering, rider dispatch and live tracking at metropolitan scale.
How it holds up.
Dispatch is built as its own service with replay tooling, and rider apps are engineered for low-end handsets and intermittent connectivity from the start.
The systemAssignment batches orders by proximity and time cost, and every decision is replayable for later audit.
Theirs, from day one.
Repositories, cloud accounts and documentation sat with the client throughout. Senior engineers wrote the production code rather than specifying it.
Ask for the full metrics on a call →More quick commerce work.
All 42 case studies →Building something like Zapp?
Tell us what you are building. A senior engineer replies within one business day. NDA on request.