Appzotic
Portfolio DeliveryLo
Apps · LogisticsFlutter apps + admin + APILive · Haryana & Himachal Pradesh

DeliveryLo

Hyperlocal delivery across food, grocery, and more

A hyperlocal delivery network — customer, driver, vendor, and admin — for food, grocery, and on-demand.

See every view Build something like this
This product holds
  • Customer, driver, and vendor Flutter apps
  • React ops admin
  • Real-time dispatch and tracking
  • COD, wallets, and payouts
DeliveryLo · Active delivery
Product
DeliveryLo
Industry
Logistics · Quick commerce
Platform
Flutter apps + admin + API
Status
Live · Haryana & Himachal Pradesh
Year
2022–2026
What’s inside

The product, module by module.

Everything a client would actually use — not a feature dump, the operating pieces of the system.

01

Live order tracking

Customer and ops share a journey from placed to delivered.

Support can see the same state the rider sees.
02

Driver economics

Offers, attendance, wages, COD collection, and QR deposit.

Riders can work the network as a job, not a side screen.
03

Vendor console

Live orders, catalog, timings, and medicine prescription review.

Stores operate without calling a dispatcher for every ticket.
Mobile productsPlatform architectureOps designCloud & DevOps
How it looks

Every view we shipped.

Click any screen to open it full size. These are the live product surfaces — dashboards, flows, and themes.

The brief

Why it exists, and what it changed.

The problem

A regional delivery company needed more than a customer app — dispatch, COD, vendor ops, and city rules had to share a backend.

What we built

Four clients on one NestJS API: Flutter for users, drivers, and vendors, plus a React admin for zones, surge, and payouts.

What changed

Orders move from cart to rider with live tracking, wallets, and city-level configuration.

01

Four-sided marketplace

Customer, driver, vendor, and admin each needed a real product, not a reskin.

Impact · APIs had to encode roles, not just CRUD.
02

City economics

Fees, surge, zones, and dispatch rules change by city and vertical.

Impact · Hard-coded pricing would have blocked expansion.
03

Cash and trust

COD, rider deposits, and vendor payouts needed a cash trail.

Impact · Without it, ops cannot close the day.
How it’s built

Delivery path, stack, and system shape.

Phase 01

Customer app

Food, grocery, electronics, medicine request, pick-and-drop, wallet, and tracking.

Phase 02

Driver and vendor

KYC, live offers, COD, earnings, store inventory, and prescription review.

Phase 03

Control plane

NestJS + Redis + sockets, with a React admin for orders, zones, and master config.

Flutter
GetX
NestJS
MongoDB
Redis
Experience
Customer Flutter app
Driver app
Vendor app
Admin
Edge & trust
JWT / OTP
Maps
Sockets
Application
Orders
Dispatch
Cart
Payments
Data
MongoDB
Redis
S3
Operations
Zones
Surge
Payouts
Help desk
Encrypted in transit and at rest End-to-end observability Independently scalable services
Impact

What a buyer should feel after launch.

4

apps on one API

Live

order tracking

City

config and surge

4 clients, 1 order

Customer, rider, vendor, and admin see one ticket.

Config-driven

New cities can launch without a rebuild.

“DeliveryLo works in a city because the rider, the store, and the customer are on the same order — not three apps pretending.”
Network operations
DeliveryLo
More work

Other products in the studio.

Project FAQ

The details behind the delivery.

How long did the project take?

The core engagement ran for a multi-app platform program. Discovery and architecture came first, followed by incremental releases and a structured transition into continuous improvement.

Why was this technology stack selected?

Flutter, GetX, NestJS, MongoDB and Redis provided the best balance of team fit, ecosystem maturity, security, delivery speed and long-term operating cost. Every major choice was documented through architecture decisions.

How were security and scalability handled?

Threat modeling, least-privilege access, automated security checks and observability were built into delivery. Load and failure testing validated the critical paths before launch.

What support followed launch?

Appzotic provided launch command, operational monitoring, knowledge transfer and a prioritized evolution roadmap. The client could choose continued product support or full internal ownership.

Start your project

Want a product that looks this considered?

Bring the workflow, the constraint, or the screenshot of what you wish existed. We’ll shape the system around it.

Schedule a discovery call Back to portfolio