Most case studies are marketing copy dressed up as insight. This one has actual numbers, actual mistakes, and the actual sequence of decisions — because vague case studies don’t help anyone building their own product.

The starting point

Driver Gill’s brief, at the start: an on-demand driver booking platform for pan-India operations, connecting riders who need a driver with verified, available drivers nearby — think of it as Uber’s structural pattern applied to a different service category. The founder came in with a clear problem statement but no locked feature list, which is the normal and correct starting point for an MVP.

Week 1–2: scoping, not building

Before any code was written, we spent two weeks writing a feature-by-feature specification — not a paragraph description, but a list of every distinct user action: “user can request a driver for a specified duration,” “driver can accept or decline a request within 60 seconds,” “admin can verify driver documents before activation.” This document eliminated the ambiguity that causes most quote variance and scope creep later.

Week 3–10: core build

Two parallel builds ran simultaneously — the rider-facing app and the driver-facing app — sharing a common backend. This was a deliberate architecture decision: on-demand platforms with two distinct user types almost always need separate, purpose-built interfaces rather than one app trying to serve both roles, even though it means more upfront build work.

Real-time location tracking was the single most expensive feature in the build — not because the Google Maps integration itself is hard, but because handling edge cases (driver goes offline mid-trip, GPS drift in dense urban areas, battery-saving modes interfering with location updates) took roughly 3x longer than the initial integration estimate.

Week 11–14: payment, verification, and the decision to cut chat

The original scope included in-app chat between rider and driver. Two weeks before the original deadline, we cut it — not because it was hard to build, but because it wasn’t necessary to validate the core hypothesis (will riders actually book drivers through this app, and will drivers actually show up reliably). Phone-call-based coordination, already familiar to users, shipped instead. In-app chat came in version 2, after the core loop was validated with real usage data justifying the investment.

This is the single decision from this build most worth remembering: cutting a reasonable-sounding feature because it doesn’t test the core hypothesis, even under deadline pressure to “just include it since we’re already building.”

Week 15–16: testing and launch

Final two weeks were driver verification workflow testing and a soft launch with a limited driver pool in one city before expanding — validating the operational side (driver onboarding, verification turnaround) at small scale before it needed to work at full scale.

The numbers

Total MVP build: ₹9–12 lakh (roughly A$16,000–22,000 at 2026 rates — see the full AUD-to-feature cost guide for how this compares across budget tiers), 14–16 weeks, team of 5 (project manager, 2 developers, 1 designer, 1 QA). What was included: rider app, separate driver app, admin panel, live location tracking, payment integration, driver document verification workflow.

Building something in this space? Send me a 5-sentence description of what you want to build. I will give you a realistic budget estimate within 24 hours — and tell you what I would cut and why. Free 30-minute call, no pitch, no obligation. Available for founders in India and Australia. Book a Free Call →

Frequently asked questions