The same person is, at different moments, a Yango moto-taxi driver earning Upahar points, an Express courier between ride-hailing shifts, a dot on the GPS dashboard's map, and, if this launches, someone paying down a motorcycle. The portfolio only compounds if these actually connect.
Every rupee of completed fare earns 1 point. Points buy real goods (momo, gloves, a raincoat, rice) at a fixed catalogue, funded by Drivra's roughly 3% commission on the fares that earn them. 1,793 riders on the roster, only 261 active in the last 30 days (14.6%): a median active rider works 6 days a month for NPR 5,509. Retention, not acquisition, is the constraint.
Redeem is an admin-run fulfilment queue today, not automated dispatch.
A Kathmandu B2B delivery platform: merchants, hubs, drivers, and orders with pickup/delivery legs and COD settlement. Its own Postgres, its own gamification system built independently of Upahar's (a second, parallel badges/quests implementation, see Architecture for why that's worth consolidating). Early-stage: 22 commits, two contributors, no test suite yet, one squashed migration.
Point-to-point delivery. Express's current model is merchant/hub-centric (a business posts an order, a driver moves it through a hub). Point-to-point, an arbitrary pickup address to an arbitrary dropoff, no merchant or hub in the loop, is a distinct job type: its own pricing (distance/time-based, not merchant-negotiated), its own matching (nearest available driver to the pickup point, not hub-queue-based), and a lighter order model that doesn't assume a merchant relationship exists.
Partner APIs. Express needs to let outside parties (e-commerce platforms,
restaurants, other apps) create and track deliveries programmatically, not just through Drivra's
own merchant portal. That means a real partner-facing API surface: API keys or OAuth
client-credentials issued per partner, per-partner rate limiting, request signing or a shared
secret on webhooks so delivery-status callbacks can't be spoofed, idempotency keys on order-creation
so a retried request can't double-book a driver, and versioned, documented endpoints (OpenAPI) so a
partner integration doesn't break silently on a backend change. None of this exists yet, and today's
CORS policy (allow_origins=["*"] with credentials allowed) is the opposite of a
partner-safe boundary. It needs fixing before any partner API ships, not after.
A live map, idle/parked-state detection via geofencing, and a genuinely useful misuse-detection
feature that cross-references GPS movement against Yango ride records to flag drivers going off-app.
No backend of its own: it's a static, client-side app that reads and writes straight into Upahar's
Supabase tables using a public anon key, protected only by row-level security policies. Data arrives
via an external Lambda ETL (trakzee-supabase-etl) polling the fleet roughly once a
minute, confirmed working and out of scope for change here (see Architecture
for why this piece specifically isn't being touched).
This is also the most directly reusable asset for the rent-to-own product: once a motorcycle is financed, its GPS trail is exactly the telematics signal an East African competitor (Moove, M-KOPA) would build fresh. Drivra already has it running, for a different purpose, on a different product. See credit scoring.
Let a driver finance their motorcycle through Drivra instead of a bank or the direct local competitor (RYD Nepal). The differentiator: it's the only rent-to-own offer that can sit inside an app the driver already uses daily, where their real earnings and tenure history, not a bank statement, can translate into faster approval and better terms. Full design: financing.html.
Eligibility pre-check against existing Upahar tenure/performance data, before any paperwork.
Citizenship + NID + license + selfie; rules-based scorecard from internal behavioral data.
Installments, an always-visible ownership-progress tracker, completion or default handling.
| Signal | Where it lives today | What it could power |
|---|---|---|
| Ride tenure, earnings consistency, streaks | Upahar (Supabase) | Rent-to-own credit scoring, already used in the v1 design |
| Delivery tenure, earnings, reliability | Express (own Postgres) | A second income/reliability signal for drivers who do both. Currently invisible to any scoring model since the databases don't talk |
| Vehicle GPS trail | GPS Dashboard (Upahar's Supabase, via Lambda ETL) | Asset monitoring for financed vehicles in a later financing phase. The infrastructure already exists |
| Repayment history | Would be new, in the financing service | The proprietary dataset every thin-file lender researched (Tugende, Watu) eventually builds toward. Drivra would build it from day one across three products instead of one |
This is the product case for the consolidation work in Architecture: a driver's full picture is currently split across a Supabase project and a separate self-hosted Postgres with no data pipeline between them. Fixing that isn't just hygiene, it's the difference between a credit score built on a third of a driver's actual activity and one built on all of it.