Doori and Doori Planner

The problem

Quoting teams needed per-kilometre costing for tenders. Each person ran a Maps formula in their own sheet and hit the individual limit of ten thousand calls a day, often halfway through a tender. Distances fetched once were fetched again by the next person. Rate workings gathered dust on individual laptops.

The product

Paste origin and destination pairs, get recommended and shortest kilometres, copy a column straight back into your working sheet. One shared quota and one shared cache, so a lane is fetched once for the whole company. Geocode-first resolution so spelling variants collapse to one place. A quota model that reconstructs the 24-hour window from the app’s own log and probes for recovery. Admin page with users, lanes and cache-hit rate. English, Hindi and Korean with full parity, because the teams and a partner work in all three.

Doori Planner came later: an EV bus lane planner that gives, for each lane, the route, every charger along the corridor, a range-gap check, charging stops and times, and fleet dispatch batching, verified against a tracker’s actual kilometres within about five percent.

Decisions I would defend

• Scope discipline. Rejected alias tables, history views, dynamic filters, refresh and pause. Each “no” protected speed.
• Read-heavy suits Sheets. Doori is happy on Sheets because it is read-heavy and cached. FleetSetu was not, because it is write-heavy. The write pattern decides the stack, not “Sheets is slow”.
• “No AI in the product” as evidence. In the AI advisory note to leadership, Doori was moved out of “AI initiatives” and into recommendation one: free tooling plus clean data delivers value before any AI spend.