01 Context
inDrive works on live negotiation. Late at night, in a peripheral neighbourhood, it often does not.
inDrive runs on live negotiation. You request a ride, propose a fare, a driver accepts or counters. That works when supply is visible and immediate. Late at night, in a peripheral neighbourhood in Kathmandu, it does not.
Driver supply clusters around central areas by evening. The few drivers available receive multiple simultaneous requests and take the closest or highest fare. You wait. Sometimes you get a ride. Sometimes you do not.
The workaround most people already use is saving a trusted driver's personal number and calling ahead to arrange a pickup. That is not a solution. It is a patch over a missing feature.
Early flow wireframes. Six screens from schedule entry through fare proposal, driver acceptance, confirmation, reminder, and pickup. Each step had to answer what happens to the agreement over the hours between booking and ride.
02 The Design Problem
Not how to add scheduling. How scheduling works when the fare is a conversation, not an algorithm.
Every major ride platform has scheduling. The question was never whether the feature should exist. The question was how it works on a platform built around negotiation rather than algorithmic pricing.
Uber Reserve locks a fare at booking because the platform calculates it. inDrive cannot do that. The fare is a conversation between rider and driver. The real design problem was this: when does that conversation happen, and what happens to the agreement over the hours between booking and pickup?
The rider
Needs a driver committed hours ahead, especially for peripheral pickups and late-night travel, when live matching cannot be relied on.
The driver
Will not commit to a peripheral ride hours ahead without a fixed agreement and fair cancellation rules. Cannot accept a fare that may get renegotiated when pickup approaches.
Both sides need commitment at different moments. The rider needs certainty when booking. The driver needs protection before accepting a ride that may require early repositioning. The design had to respect how inDrive actually works, not how Uber works.
03 The Core Insight
The lock already exists on immediate rides. Scheduling tests whether it can survive the waiting period.
"The fare is a conversation between rider and driver. When does that conversation happen, and what happens to the agreement over time?"
The constraint that defined every decision
In a standard inDrive ride, the fare locks the moment a driver accepts. That model already works. Scheduling adds hours between acceptance and pickup, and without a clear rule, either side could try to reopen negotiation when the trip gets close.
04 What I Did
Four rules shaped by how inDrive actually works.
Every decision was downstream of understanding inDrive's negotiation model, not copying Uber Reserve.
Decision 01
Fixed fare at booking, accepted or ignored by drivers
Scheduled rides use a fixed fare model. The rider sets a fare at booking; drivers see the time, route, and amount, and either accept or ignore. Once accepted, the fare holds until pickup. No counter-offers at the door, no repricing as pickup approaches. A deliberate departure from inDrive's negotiation model, scoped only to this use case. Real-time rides stay unchanged.
Decision 02
One to twenty-four hours only
Under one hour is real-time and uses the existing flow. Beyond twenty-four hours, drivers in Kathmandu cannot meaningfully commit to a peripheral pickup or fare conditions that may change overnight.
The window targets the actual use case: same-day planning, not scheduling days ahead.
Decision 03
Cancellation policy built for both sides
Rider cancels more than two hours before pickup: no charge. Rider cancels within two hours: flat fee of Rs. 100, shown explicitly at booking and again before cancellation confirms.
Driver cancels within two hours: partial fare compensation paid to the rider. Drivers who accumulate cancellations lose access to scheduled rides entirely. The two-hour threshold is longer than Uber Reserve's one-hour window because drivers accepting peripheral late-night rides in Kathmandu may begin repositioning significantly earlier than in a dense urban environment.
Decision 04
Making driver commitment visible
The strongest concern that came up in research was not about price. It was: will the driver actually show up? The confirmation screen shows driver name, photo, vehicle, and approximate current location to make the commitment feel real rather than abstract.
One hour before pickup, both parties receive a reminder and the driver confirms with one tap. If they do not confirm within fifteen minutes, the rider gets an alert and options. The goal was an early warning system, not a surprise cancellation at the door.
05 Outcome
A concept, not a shipped product. The principle is what lasted.
The clearest thing it produced was a design principle: when adding a feature to an existing product, respect the logic the product is already built on. Every decision here was downstream of understanding how inDrive actually works, not how Uber works. That difference shaped everything.
What Landed
Framing the problem as negotiation timing, not "add a schedule button," gave every decision a clear rationale
A fixed fare model for scheduled rides only, leaving real-time negotiation untouched, kept the concept coherent with inDrive's identity
The one to twenty-four hour window kept the feature aligned with real Kathmandu use cases instead of generic scheduling
Driver commitment UI addressed the rider's real anxiety: not whether the fare was fair, but whether someone would actually arrive
What I Would Do Differently
The entire feature depends on one assumption I never tested: that drivers in Kathmandu will accept peripheral rides hours in advance at a fixed fare
I designed the incentives and cancellation rules around that belief. Before this goes anywhere near development, that assumption needs validation with actual drivers on the ground
A concept that stands or falls on unvalidated driver behaviour is not ready to ship