Skip to content
Peakride
Agency Architecture Case Study

Peakride: Offline-First Fleet Operations for Mountain Towns

How our digital agency engineered an offline-first vehicle rental platform that runs 100% inside the browser, solves Himalayan 3G dead-zones, and cryptographically resolves double-booking conflicts without an external database.

Verification

193+

Unit & property tests passing across pricing, crypto, sync, and rules.

Bandwidth Savings

56%

In-browser image compression before upload (251 KB → 111 KB).

Cloud DB Required

0

Deterministic local Dexie IndexedDB with reactive multi-tab sync.

Counter Walk-In

< 60s

From customer arrival to keys in hand with digital licence capture.

01 · The Challenge

The reality of mountain tourism operations

Mussoorie, perched at 2,000 meters in Uttarakhand, sees massive influxes of weekend tourists escaping the heat of Delhi and Dehradun. Local scooty and motorcycle rental operators run brisk, high-stakes businesses, but are hamstrung by five pervasive friction points:

1. Spotty Himalayan Connectivity

Between Library Chowk and Kulri Bazaar, dense hills create cellular blackouts. Cloud-only SaaS apps spin and fail exactly when a tourist is standing at the counter.

2. Weekend Double-Bookings

Shops with multiple counters maintain paper diaries or uncoordinated WhatsApp chats. Two staff members routinely promise the same Royal Enfield Classic 350 to two different customers.

3. Bitter Damage Disputes

Returning riders dispute existing scratches on steep hill descents. Without verifiable timestamps, operators forfeit legitimate repairs or tourists feel cheated of their ₹2,000 cash deposit.

4. KYC Privacy & Data Sprawl

Taking raw photocopies of driving licences and IDs leaves sensitive citizen documents vulnerable in open drawers or staff phones, violating modern data protection standards.

02 · The Solution

Two interconnected, local-first applications

Instead of building a typical thin client tethered to a remote backend API, we built an offline-first distributed system consisting of two unified interfaces:

Customer Booking Experience

Tourists book easily on their phones: transparent hourly & daily rates, dynamic monsoon and peak holiday multipliers, 25% advance hold via simulated UPI QR code, client-side document compression (56% bandwidth reduction), and AES-GCM 256 encryption.

Operator Shop Counter Console

Counter staff work at lightning speed: PIN authentication (2580), live Today board, interactive 3-day fleet timeline with collision prevention, 60-second walk-in flow, cash drawer ledger balancing, and cryptographic inspection workflows.

03 · The Core Innovation

Why arrival order & domain rules beat CRDTs

"Built for a hill town where the network drops constantly. The operator can take a booking with zero connectivity — it queues in IndexedDB and reconciles on reconnect, including conflict handling when two devices booked the same scooty offline."

When building offline collaborative applications, engineers frequently reach for CRDTs (Conflict-free Replicated Data Types) or Operational Transformation. However, in rental operations, a physical vehicle is an exclusive, indivisible resource. You cannot merge two bookings for the same motorcycle. Merging edits or averaging time intervals is nonsensical when only one physical handlebar exists.

Instead, we designed an authoritative pure domain rule engine (R1–R10) executed with idempotent operation queues. The supreme rule of the physical world governs resolution: Physical vehicle handover trumps a paper booking.

Counter A (Library Chowk)IndexedDB: pw-device-counter-aSimulated HQ (Authority)IndexedDB: pw-hq · applyOp Rules R1–R10Counter B (Kulri Bazaar)IndexedDB: pw-device-counter-b1. Signal Drops: OFFLINEWalk-in: Classic 350 for Priya2. Signal Drops: OFFLINEWalk-in: Same Classic 350 for Rohan3. Physical HandoverKeys given · 6 photos sealed with SHA-256B Reconnects First4. Domain Conflict EngineRohan's op arrives first → Held at HQCounter A op arrives with Sealed PickupA Reconnects5. Rule R4: Physical Handover WinsPriya stays ON-ROAD (Physical truth)Rohan moved to Conflict Inbox with suggestions6. Counter B ResolutionAlert: "Double-booked bike"1-Click: Reassign Rohan to Hunter 350

Domain Rules R1–R10 Summary

R1Idempotent Ops: Duplicate operation IDs are accepted idempotently without side effects.
R2Free Vehicle Create: Uncontested walk-in or booking commits cleanly at version 1.
R3Turnaround Guard: Bookings require a mandatory 30-minute turnaround buffer. Overlaps generate a VEHICLE_TAKEN conflict with ranked same-class vehicle alternatives.
R4Physical Handover Ground Truth: When a counter completes an in-person key handover with photographic inspection on a conflicted bike, that booking immediately claims the vehicle (on-road), while the conflicting virtual reservation is displaced into the Conflict Inbox for 1-click reassignment.
R5Handover Reinstatement: An accidental cancellation is automatically reinstated to on-road if physical vehicle handover inspection arrives.
R6On-Road Immunity: A booking cannot be cancelled while the vehicle is actively on the road.
R7Extend Collision Guard: Extensions into subsequent reservations trigger EXTENSION_BLOCKED with rebooking options.
R8Duplicate Return Guard: Returned vehicles reject secondary return records; ledger settlements are always appended.
R9Conflict Reassignment: Staff can reassign conflicted customers to available bikes with 1 click; original agreed price is preserved.
R10Optimistic Concurrency: Stale writes on mutated attributes (endAt, vehicleId, status) are cleanly rejected with full audit detail.

04 · Data Integrity

Double-booking prevention at the data layer

In our client-side demo, overlap prevention is enforced inside single Dexie read-write transactions. When deploying to a production backend, this same mathematical guarantee maps directly to PostgreSQL GiST exclusion constraints:

ALTER TABLE bookings
ADD CONSTRAINT no_overlap
EXCLUDE USING gist (
  vehicle_id WITH =,
  tstzrange(start_at, end_at + interval '30 minutes') WITH &&
)
WHERE (status IN ('held', 'confirmed', 'on-road'));

This eliminates race conditions at the database engine level, ensuring zero double-booking is physically possible even under extreme concurrent requests.

05 · Dispute-Proofing

SHA-256 inspection seals & tamper evidence

To eradicate customer disputes over scratches, Peakride uses client-side cryptographic hashing:

  • Photo Capture Hashing: At pickup, 6 guided photographs (front, left, right, rear, odometer, fuel) are captured and immediately digested into SHA-256 hashes in memory.
  • Seal Chaining: The inspection payload (odometer, fuel bars, damage zones, and photo hashes) is sealed into a root hash. Upon return, the return inspection chains to the pickup seal hash.
  • Customer Verification Report: When a tourist opens /report, the browser recomputes the cryptographic hashes of every photo and reading from storage. If anyone modified a number or photo, the badge instantly switches from Verified ✓ to Tampered ✗.

06 · Security & Compliance

Privacy by design under India's DPDP Act 2023

We architected Peakride to respect the Digital Personal Data Protection Act, 2023 principles:

Client-Side Encryption

Driving licences are encrypted using AES-GCM 256 with non-extractable keys before hitting disk.

Salted Licence Hashes

Raw licence numbers are never stored. Only salted SHA-256 hashes and the last 4 digits are retained.

Automated Purging

Customer KYC documents are automatically wiped after 7 days, and photos after 90 days.

07 · Market Differentiation

How Peakride compares to alternatives

FeaturePaper RegisterGeneric Rental SaaSPeakride
Offline Mountain Capability Works offline Fails without 4G Full offline + outbox queue
Double-Booking Handling Frequent conflicts Simple rejection Domain rules R1–R10 + handover truth
Scratch Dispute Proofing Memory & argument Unverified phone photos SHA-256 chained inspection seal
Customer KYC Security Paper xerox in open drawer Plaintext files in S3 AES-GCM + 7-day auto purge

08 · From Demo to Enterprise

Production roadmap & backend swap points

This portfolio showcase proves the complete user experience, data schema, and business domain logic client-side. To transition from this zero-database demo to multi-location production, our agency modularised clean interface adapters:

SyncTransport → WebSocket / HTTP

Swap SimulatedTransport for a Node/Go sync endpoint with PostgreSQL row-level replication.

PaymentProvider → Razorpay / UPI Stack

Switch the simulated QR code to Razorpay dynamic UPI intent with webhook callbacks.

WhatsApp Links → WhatsApp Cloud API

Replace deep-links with automated booking confirmations, PIN reminders, and return reports via Meta's Cloud API.

ID Upload → DigiLocker / Aadhaar API

Direct verification of DL categories against India's Sarathi Parivahan database.

Ready to build mission-critical web software?

Our studio specializes in offline-first web applications, distributed state synchronization, cryptographic audit trails, and high-conversion UX design.