The Problem
A Delhi-based founder came to us with a specific problem: small logistics and courier companies in India were managing their delivery operations entirely on WhatsApp and spreadsheets. Dispatchers would share delivery addresses via WhatsApp groups, drivers would mark pickups complete in a shared Google Sheet, and tracking updates were copy-pasted manually into customer messages.
It worked — just barely — for operations handling 50–80 deliveries per day. But at 150+ deliveries it became unmanageable. Jobs got missed. Customers got no updates. The dispatcher was spending four hours a day on status updates alone.
The founder had validated the problem by talking to 30 courier companies in Delhi and Gurgaon. Seven of them said they'd pay for a solution. He came to us to build it.
What We Agreed to Build
The first conversation was about scope. The founder had a long list of features — real-time driver tracking, customer notifications, route optimisation, invoicing, analytics, a mobile app for drivers, a web dashboard for dispatchers, customer-facing tracking portal, API integrations with major e-commerce platforms.
We pushed back. For an MVP, we needed to identify the single most important thing to test: would dispatch teams actually adopt the tool, or would they stick to WhatsApp because they know it? Everything else was a distraction until we had an answer to that question.
We agreed on a scope of three things:
- A mobile app for drivers (Android only, since all seven target customers' drivers used Android) to accept jobs and mark deliveries complete
- A web dashboard for dispatchers to create jobs, assign drivers, and see live status
- Automated WhatsApp messages to customers when status changed (using WhatsApp Business API — keeping the familiar medium while automating the manual work)
Route optimisation, invoicing, customer portal, and e-commerce integrations all went to a post-MVP list.
The Build: 10 Weeks
Weeks 1–2: Design. Figma wireframes for all screens — the driver app flows and the dispatcher dashboard. We ran the wireframes past two of the seven interested companies to catch usability issues before writing code. Three significant flow changes came out of those sessions.
Weeks 3–6: Core development. Flutter for the driver app (easier to maintain cross-platform later), Next.js for the dispatcher dashboard, Node.js backend with MongoDB. The database schema was designed with multi-tenancy from the start — each logistics company as a separate account with isolated data.
Weeks 7–8: Integrations and edge cases. WhatsApp Business API integration took longer than expected — Meta's review process for Business API access added a week of waiting. We used the time to harden error handling for the offline scenarios drivers encounter frequently in areas with poor connectivity.
Weeks 9–10: Testing and launch prep. Testing on a range of real Android devices, fixing the issues that only appear on actual hardware, app store submission, and onboarding the first two paying customers before the public launch.
Key Technical Decisions
Flutter for the driver app, not React Native. The driver app needed to work reliably on low-end Android devices (the ₹6,000–10,000 range used by most delivery drivers) and handle background location tracking without the battery drain issues that plague some React Native implementations. Flutter gave us more control over this.
WhatsApp over SMS for customer notifications. Early testing showed dramatically higher open rates on WhatsApp versus SMS (over 90% vs under 40%) for this audience. The API setup was more complex but the user experience was significantly better.
MongoDB for the job data. Job records had a variable structure — different companies track different fields, add notes in different formats, and attach different documents. A flexible document schema made this much easier than a rigid relational structure would have.
Results After Launch
Three months after launch, the product had onboarded 11 paying companies in Delhi, Gurgaon, and Noida. The average dispatcher reported saving 2–3 hours per day on status updates and customer communication. Customer complaint rates dropped significantly at companies using the platform compared to their previous period.
The founder has since raised a seed round and the product is now in active development with a full-time team. The MVP codebase we built is still the core of the production product.
What We'd Do Differently
The offline handling for the driver app was underspecified in the initial scope. Drivers in areas with poor connectivity needed the app to queue completed deliveries and sync when they got a signal — we built this in week 8 when it should have been a week 3 requirement. Better initial discovery would have caught this.
If you're building something in the logistics, field operations, or marketplace space and want to talk through what an MVP scope should look like, get in touch.