Use case · Mobility and last-mile

Retire the dispatch, ETA and tracking layer you keep rebuilding

Cab aggregators, delivery fleets and quick commerce all hit the same wall: a custom dispatch, ETA and tracking layer that costs years of engineering, and riders who defect to the Google Maps app to navigate. Lepton integrates the managed Google Mobility stack instead, so your engineers go back to building what only you can build.

Get a demo →

The pattern

Everyone in mobility rebuilds the same layer

A cab platform, a delivery fleet and a quick commerce app look different from the front, but underneath they all need the same machinery: dispatch, trip lifecycle, ETA, live tracking and journey sharing. Most teams set out to build it on the Core APIs, and that is exactly what the Core APIs invite.

What you are really paying for

Two costs, not one

The team you cannot redeploy

Dispatch, tracking, trip lifecycle, ETA and journey sharing are a permanent surface to own. Every engineer on it is an engineer not on your differentiator.

Drivers leaving your app to navigate

When turn-by-turn lives outside your product, the driver switches to the Google Maps app and you lose the trip from your own screen mid-journey.

Per-call costs that swing with volume

A single ride can fan out into 8 to 12 metered API calls. At scale that is unpredictable, and teams start throttling calls and degrading the experience to contain it.

Routing that ignores the two-wheeler reality

India quick commerce runs on bikes through gullies and flyovers. Car-shaped routing gives the wrong ETA and the wrong path on the final stretch.

The managed alternative

The Mobility stack does the layer for you

Google's managed Mobility stack replaces the custom orchestration layer with components you integrate rather than build. Lepton does the integration end to end, from the GCP project and service-account setup through the SDK wiring, so the stack lands inside your product, not beside it.

  1. 01

    Fleet Engine · The dispatch and trip backend, managed

    Vehicles, trips and ETAs run on Google's managed backend, so the lifecycle you would have hand-built becomes configuration and API calls.

  2. 02

    Driver and Consumer SDKs · Driver app and rider tracking, out of the box

    The driver-side and the rider-side tracking experiences ship as SDKs instead of as two more services for you to maintain.

  3. 03

    Navigation SDK · Turn-by-turn that stays in your app

    Brand-customizable turn-by-turn lives inside your product. Drivers and customers see identical routes, and mid-trip re-routing pushes to the driver automatically, so nobody leaves to navigate.

  4. 04

    Two-wheeler routing · Built for the Indian last mile

    Bike-specific paths, gully shortcuts and flyover anticipation, purpose-built for India quick commerce and kept current by Google's India operations.

The decision, line by line

Build the layer, or integrate the managed one

Same Google pricing on both paths. What changes is which of these your team owns, how long it takes to reach production, and what a single ride meters.

Mobility and last mile · The two paths
Every piece the layer needs, and who provides it on each path
Same Google pricing either way · the difference is what your team owns · benchmarks as cited on this page
PER TRIP
instead of 8 to 12 metered calls per ride
What has to exist Built on the Core APIs Integrated on the Mobility stack
Dispatch and trip lifecycle
Build

Yours to design, build, run and keep running

Integrate

Fleet Engine, the managed backend for vehicles, trips and ETAs

Live tracking, driver and rider
Build

Two more services to write and maintain

Integrate

Driver SDK and Consumer SDK, with the Fleet Tracking Library on top

Turn-by-turn navigation
Build

The driver switches to the Google Maps app and the trip leaves your screen

Integrate

Navigation SDK inside your product, with mid-trip re-routing pushed to the driver

The Indian last mile
Build

Car-shaped routing on the final stretch

Integrate

Two-wheeler routing, with gully shortcuts and flyover anticipation

Time and team to first production
Build 12–18 months

15 to 25 engineers, for a cab-aggregation orchestration layer

Integrate 16 days

An integration engagement: discovery on day 1, phased rollout from day 8

Team to keep it running
Build 8–12

Engineers ongoing, for a quick-commerce layer

Integrate None

No standing orchestration team; you own your own product code

What one ride meters
Build 8–12

8 to 12 metered API calls fan out from a single ride

Integrate 1

One completed trip, on a Mobility Plan; cancelled rides cost nothing

build figures 15–25 engineers over 12–18 months, 8–12 ongoing, 8–12 calls per ride 16 days discovery day 1 to phased rollout day 16, the motion on our how-it-works page
Fig. · The two paths, line by line. The engineering and per-ride figures in the build column are the deck benchmarks quoted on this page and describe no named operator; the managed column lists only Google components we integrate. Google sets the pricing on both paths.

Same route inside the app and on the map

When navigation lives outside your product, the driver follows one route and your tracking shows another, and the trip slips out of your control the moment they switch apps. The Navigation SDK closes that gap: the route the driver follows is the route your map shows, with re-routing handled for you.

The commercial shape

Priced per trip, not per call

The Mobility stack changes the meter, not just the architecture: Mobility Plans price per completed trip, and rides that get cancelled cost nothing. Our job is to map your volumes to the construct that fits, so the bill stops swinging with traffic.

15–25 engineers, and 12 to 18 months, to build the orchestration layer in-house
8–12 engineers ongoing just to maintain a quick commerce one
8–12 metered API calls per ride that per-completed-trip pricing replaces

Compliance

Built with MV Aggregator Guidelines 2025 in reach

For cab aggregators, the same managed stack carries the compliance hooks the 2025 guidelines ask for. Fleet Engine real-time tracking can feed State Command and Control Centres, route-deviation detection is built into trip monitoring, and panic-button integration is ready to wire in. You get the operational requirement from the platform you already run trips on, rather than as a second system bolted to the side.

Proof

What the migration looks like in the numbers

One delivery operator that moved off a self-built geo stack onto the managed approach saw the pattern hold: address accuracy rose from an 85% ceiling to 95% and above once Address Validation and Address Descriptors were in place, total geo spend came down by around 30%, roughly eight engineers were freed to redeploy, and the migration cleared its geo-stack P0s. The operator stays unnamed, but the shape of the win is the one this stack is built to produce.

Delivered as India's largest Google Maps Platform reseller, and a Premier Partner for 10+ years across India, the Middle East and Singapore
  • Google partner 15+ years
  • Premier Partner 10+ years
  • Use-case-to-API matching
  • SDK and GCP integration
  • Cost engineering
  • 24x7 local support
Get started

Map your mobility stack to the right Maps APIs.

Bring your dispatch, ETA and tracking pain. We will scope the managed Mobility path and the cost construct against your real volumes.

Get a demo →