Pakka Logistics — Porter-Style Delivery Platform

Live tracking in Pakka has two parts. The driver's position streams to the customer over Socket.IO, which costs nothing per update. The road line on the map comes from Google's Directions API through our backend, which caches routes in Redis. Every Directions call is billed.

The bug

The route hook in both apps re-ran whenever the driver moved more than 11 metres, throttled to once every 10 seconds. The server's cache key rounded coordinates to about 1.1 metres, so a moving vehicle missed the cache every time: one billable call every ten seconds per open map, or ₹2.58 a minute. The driver's trip screen is the navigation view and stays open for the whole delivery, so a 30-minute trip billed roughly ₹77 on the driver's phone alone, whether or not a customer was watching. Both call sites carried a comment saying "one fetch per leg". It was not true.

The fix

• Driver movement alone never fetches a route while a road line is on the map.
• A route is fetched when the leg changes (pickup to drop) or when the driver is more than 150 m off the drawn line, at most once every 30 seconds so GPS noise at the edge cannot thrash.
• The ETA is recomputed on the phone from the distance left along the line, and the line is trimmed to the road ahead.

Distance to the line is measured to the nearest segment, not the nearest point. Server polylines are sparse: a driver halfway along a straight stretch can be 500 m from both ends while sitting on the road. A nearest-point check would call that a deviation and bring the cost straight back.

One gap remains, found in October 2026 while capturing the apps against a local backend with no Google key: when Google returns no route at all, the map stays empty, so every position update fetches again and the booking preview retries until the rate limiter answers 429. Failed fetches need the same back-off as successful ones.

How we proved it

The decision logic is one pure function shared by both apps, so the test replays a simulated 25-minute drive and counts calls: 151 position updates, one fetch. A second test makes sure a driver who really leaves the route does trigger a refetch, so "fetches once" cannot pass by never fetching again.

We traced one booking through the code and priced every third-party call it makes, for a cash-paid trip (an online payment adds the gateway fee).

Google Maps is ₹7.45 of the consumer trip's ₹7.86. Matching a driver costs nothing: it runs on a MongoDB $geoNear query and local distance maths, never on Google. A business trip costs less than half because nobody types an address and the portal draws no map, so what is left is the cost of the delivery itself.

What changed because of it

Cost follows trips, not fare. A two-wheeler runs about 4.7 times as many trips as a large truck to use the same plan allowance, so plans now carry trip caps for two- and three-wheelers, while trucks never reach theirs.

Business quotes were priced on straight-line distance × 1.25. We measured that against 90 real Bengaluru routes: it under-charged on 72 of them, and by 10% on average across all 90. Business quotes now use real road distance from Directions, cached per route, because a 43-paise route call recovers ₹23–67 of fare.

The unit prices are Google's and MSG91's public rates; the study marks them to be checked against a real bill. The ranking of where the money goes does not depend on them.

Every driver has a wallet backed by a ledger. Online fares, tips and UPI collections add to it; commission, plan purchases and the cash a driver is holding count against it. A driver works either on a prepaid plan, which unlocks an amount of business with no per-trip commission while it runs, or on commission. A new driver starts on commission and unlocks plans after a set amount of delivered business.

Plans are paid from the balance

Google and Apple take 15–30% of in-app purchases of digital features, and a driver plan could be read that way; customer fares, a physical service, are exempt. We read both stores' rules, removed the card option, and made a plan come out of money Pakka already owes the driver. The app asks before it spends.

Cash, settle-up and UPI

Commission drivers have a cap on the cash they may hold, and Settle up lets them pay Pakka's share back through Razorpay. A UPI QR on the driver's phone lets a customer pay Pakka directly, so his balance grows instead of his debt.

The books

Every money movement posts a double-entry journal entry, and one whose debits and credits differ cannot be saved. Entries are append-only and corrected by reversal; each stores a SHA-256 hash of itself and the previous entry, so an edit made straight in the database breaks the chain. The books export as Tally XML.

Payouts

A withdrawal debits the balance at once and joins a queue in the console. On approval, a worker in the mobile backend sends it through RazorpayX and webhooks confirm it; a failed payout comes back as a new ledger entry. That path is built and tested against RazorpayX's webhooks but ships switched off, so approved withdrawals are paid by bank transfer from the same queue for now.

Before production, a probe of the money routes found two confirm endpoints that trusted figures sent by the phone. Both now read the plan, the driver and the amount from the Razorpay order itself.

Pakka for Business is the portal a company's dispatch desk works from. A new company signs up, submits its GSTIN, PAN and billing address, and cannot ship until Pakka's operations team approves the KYC.

Shipping

• Single and multi-drop shipments from saved addresses. The server prices every vehicle class for the whole route, extra stops included, and marks the classes that cannot carry the load, with the reason.
• Bulk CSV upload. Every row is validated and priced on the server before anything is booked; a row that breaks a rule is flagged, not booked.
• Recurring runs. Daily, weekday or weekly schedules create shipments by themselves at a set Indian time.
• Own fleet. A company adds its own drivers, who use the same Pakka Driver app but are offered only that company's work. A shipment the fleet does not take in time (five minutes by default) overflows to Pakka's pool. Company vans are checked out to a driver, with a trail and geofence crossings.
• Receiver tracking. Each drop gets a no-login link with status, the driver's first name and vehicle, and progress.

Billing

A daily job assembles draft invoices from delivered shipments for each Indian calendar month. A person issues them, which takes the next gapless serial in the financial-year series and freezes the amounts and both parties' GST details. A shipment can be billed only once; voiding an invoice releases its shipments for re-billing.

Developer API

Companies create live and sandbox keys in the portal and book shipments from their own systems. Keys are stored as SHA-256 hashes so a request is matched by lookup, not by trying every stored hash. Webhooks are signed with HMAC-SHA256 over a timestamp and the body and retried at 1 m, 5 m, 30 m, 2 h, 12 h and 24 h; an endpoint that fails eight times in a row is switched off. Sandbox events never reach a live endpoint, and redirects are not followed.

We do not report progress from a to-do list. A route-inventory tool lists every operable API route and reads, from a ledger the probes write, whether each one has been driven. On 22 September 2026 it read 260 of 270 routes operated (96.3%), with support and settings fully covered and money at 51 of 52. The tool exists because a hand-kept checklist once read "216 / 216 — 100%" while regenerating it gave 216 of 244: 28 routes had shipped and never been run.

Release ledger

Every APK is recorded with its git tag, commit, sha256, signing certificate and the backend commit it expects. Two builds had already shipped under one version number with different contents, and one build that said BUILD SUCCESSFUL still pointed at the build laptop because Metro had cached the bundle. A verifier script now reads the API address out of the built APK and checks the certificate before anything is shared.

The pre-Play Store QA pass

On 14–15 October 2026 we click-tested and break-tested both apps screen by screen on an Android 16 emulator, the way store testers work: back gestures, killing the app mid-flow, double taps on submit, airplane mode, a stopped server. 28 defects were logged, each with its own root-cause folder, and all 28 were fixed. Two would have blocked release:

• the apps asked for access to all photos for one-off picks, which Play's photo policy rejects. They now use the system photo picker;
• a Pay-now booking was offered to drivers before it was paid, so an abandoned checkout could be delivered for free. Online bookings now wait as "awaiting payment" and are searched only once the payment verifies.

Release builds 1.0.13 (customer) and 1.0.14 (driver) were cut on 15 October. The pass continues through the remaining checklist before the apps are submitted to Google Play.