Drivra runs three live products built up over about a year, plus a new rent-to-own financing product being designed now. This page is the complete summary: what exists, what's live and fine, what's live but needs rethinking, what isn't built yet, and what the next six months cost. The other pages go deeper on any one piece; you don't need them to get the full picture here.
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.
Driver rewards. FastAPI + Supabase. 1,793 drivers on the roster, 261 active in the last 30 days (14.6%). Retention, not acquisition, is the constraint. The most tested, most production-hardened piece of the stack.
B2B delivery. Own Postgres, own gamification system built independently of Upahar's. Early-stage: 22 commits, no test suite, no managed backups, and a critical CORS gap (below). Needs partner APIs and point-to-point delivery before it can grow past merchant/hub orders.
Fleet telematics: live map, idle detection, and a genuinely useful misuse-detection feature. No backend of its own: it reads and writes straight into Upahar's Supabase tables with a public key, protected only by row-level security. That pattern is the single biggest platform risk on this page.
Let a driver finance their motorcycle through Drivra, using their Upahar activity history as the credit signal instead of a bank file. The product this whole document was triggered by. Full design on Rent-to-Own.
Two of the four systems above already share one database in a way that's caused a real production incident and a documented security gap. A new product holding KYC documents and loan ledgers should not sit inside, or next to, that pattern.
Four repos, two GitHub organizations, one Supabase project doing more than it should.
Green: built and fine. Amber: built, needs rethinking. The shared Supabase project and Express's unmanaged Postgres are the two amber boxes worth the most attention.
| Product | Repo / org | Stack | Deploy |
|---|---|---|---|
| Upahar | husig-ai/yapigo | FastAPI, SQLAlchemy 2.0, Alembic, Jinja2 + HTMX admin | Single stateless EC2 container behind Caddy, GitHub Actions to ECR |
| Express | husig-ai/drivra_express_backend | FastAPI, SQLAlchemy 2.0, Alembic | EC2 via ECR + AWS SSM, mirrors Upahar's pipeline |
| GPS Dashboard | Drivra-Mobility/gps | Vanilla JS/HTML/CSS, Supabase JS client, Leaflet | Static hosting |
| GPS ETL | trakzee-supabase-etl (not in this workspace) | AWS Lambda | Confirmed working, out of scope |
| Analytics tool | husig-ai/drivra | Single-file HTML + Chart.js | None, ad hoc, manual CSV upload |
| Marketing site | Drivra-Mobility/drivra-web | Static HTML/CSS/JS | Static hosting |
Repos split across two GitHub orgs (husig-ai and Drivra-Mobility) with no single infra-as-code source of truth: worth deciding if that's intentional before a fifth product adds to it.
allow_origins=["*"] plus
allow_credentials=True. Any website can make authenticated requests against Express
today.create_all() and
Alembic), which can silently diverge.drivers tables,
no link.Full ranked list with the specific low-lift fixes and the larger investments: Architecture.
The fix is not a bigger shared database: Upahar and GPS Dashboard already sharing one is the worst-behaved part of the stack. The fix is narrower and smaller than that.
This is deliberately right-sized: a small identity service behind a plain API, no message bus; one small Postgres reporting database, no warehouse product. That's confirmed against what teams at this scale actually adopt, not an enterprise default. Full reasoning and the "explicitly not needed yet" list: Architecture.
A local competitor, RYD Nepal, already runs this model with no app and no credit check. Drivra's edge: this can live inside an app drivers already use daily, where real earnings and tenure history, not a bank statement, drive approval and terms.
Only a licensed lender may originate consumer loans in Nepal (BAFIA ยง31). Recommended path: partner with a licensed hire-purchase company (Path A), Drivra as the distribution and underwriting-data layer. Avoids a NPR 300M capital bar; still needs counsel to confirm repossession rights for Drivra's specific structure.
Standalone service, own repo, own Postgres, own Supabase project (never shared with Upahar/GPS). Reuses Upahar's proven FastAPI + SQLAlchemy + Alembic stack. DIY Textract + Rekognition eKYC at roughly $0.07/verification, about 30 to 100 times cheaper than a global vendor.
Rules-based scorecard, not ML: tenure, earnings consistency, streaks, tier, all already in Upahar. Cold-start applicants get a guarantor or higher down payment instead of a decline. No telematics/remote-disable in v1: reputational risk outweighs the benefit this early.
Full competitive research, the regulatory citations, the data model, and the payments design: Rent-to-Own.
Platform hardening and the financing product aren't competing priorities. The hardening work is what makes the financing product's credit signal trustworthy.
Green: starting now. Blue: sequenced after. Full phase content: Roadmap & Cost.
This isn't a speculative strategy memo. The product-portfolio and
architecture sections come from directly reading the five relevant repositories
(yapigo, drivra_express_backend, gps_dashboard,
drivra, drivra-web): their models, migrations, deployment configs, and
their own READMEs. The rent-to-own design draws on that same codebase reading plus external
research: competitor products (RYD Nepal, M-KOPA, Tugende, Watu, Moove), Nepal's lending and KYC
regulation (NRB/BAFIA), Nepal's payment rail landscape (eSewa, Khalti, Fonepay, ConnectIPS), and
cost/infra benchmarking. Where a number is a genuine estimate rather than a confirmed fact, it's
labeled as one.