Dandii

Addis Ababa's public transport system is large, real, and almost entirely illegible to the people who use it. The DT4A GTFS 2026 feed alone covers 447 routes across Anbessa (the city bus operator), Sheger, Alliance, a wide array of minibus (shared taxi) associations, and the Addis LRT — but that structured data has historically had nowhere to live for a rider. The majority of trips in the city happen on minibuses, an informal-feeling but heavily used mode that most transit apps ignore in favor of "official" bus and rail lines. Dandii's premise is that if you want a transit app that's actually useful in Addis, the minibus network can't be an afterthought — it has to be first-class, which is why the brand mark itself is a minibus silhouette rather than a generic bus or metro icon. So the problem splits into two related failures Dandii is addressing: 1. Riders can't see or plan around the network. There's no single, current, visual map of "everything that moves people in this city" — which routes exist, where they stop, how often they run, what they cost, and whether a given route is even open today (dynamicclosures happen and aren't broadcast). Dandii's answer is a Google-Maps-style public map that renders all route shapes on a web map with route and stop search, a detail sheet per route (stops, headways, fares, closure banners), and an OpenTripPlanner-powered journey planner so a rider can ask "how do I get from A to B" and get a real multimodal answer. 2. The data that makes that map trustworthy doesn't stay trustworthy by itself. Fares change, routes close for construction or reorganize, and operators shift — and a GTFS feed that's accurate at import time drifts out of date. Dandii treats this as an operations problem, not just a data problem, and builds a role-based console for transport officials: assigning route ids to operators, opening/closing routes with a reason and date range, and managing flat vs. tiered ETB fare pricing. Access is gated by a real RBAC system enforced in middleware, layouts, and every server action — because letting the wrong actor edit fares or close a route is a trust problem, not just a UX one. The emerging third piece: crowdsourced accuracy. The freshest addition tackles the fact that officials alone can't keep all the routes worth of fares current — riders notice price changes before any operator files them. Dandii already has a fare-proposal pipeline (rider submits a correction → console review → approve/reject/supersede), but until now there's been no reason for a rider to bother. The planned "Fare Scout" system borrows Google Maps Local Guides' model: reward approval, not submission, so points track accuracy rather than volume, with levels and badges layered on top to make contributing feel like status rather than a form to fill out. It's explicitly designed so junk submissions net zero and reviewers can't self-approve. Underlying philosophy. Across all of this, Dandii is deliberately utilitarian rather than decorative — "riders need clarity over decoration" is stated directly in the design system. The map is the product; chrome stays quiet. It leans on category conventions riders already know from Google Maps (floating search over a full-bleed map, bott