This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass
What I Built
OyaGo is a web app that tells you how to get around Lagos, Nigeria by public transport. You ask in plain English or Nigerian Pidgin, and it gives you bus-by-bus directions written the way a local would give them.
hint: Oya Go means "Let's Go" in Nigerian Pidgin
The problem, for anyone who has never been to Lagos
Lagos is one of the largest cities in Africa, with well over 15 million people. Most of them move around on a transport system that no map app really understands:
Danfo: yellow minibuses that run fixed routes but have no printed timetable or route map. A conductor hangs out of the door shouting the destination.
BRT: a bus rapid transit system with dedicated lanes on some major roads.
Keke (motorised tricycles) and okada (motorcycle taxis) for the last stretch.
Directions here are passed on by word of mouth, and they sound like this:
"Enter Oshodi bus. When you reach under-bridge, drop, cross to the other side, then enter Yaba bus."
If you're new to the city, a student, a young graduate posted here for national service, or just going somewhere unfamiliar, this knowledge is hard to come by. Google Maps will happily tell you to drive. It won't tell you which danfo to board, what the conductor will shout, or roughly how much the fare is.
So people stay home, take expensive ride-hailing cars like uber and bolt, or rely on whoever they can call.
What OyaGo does
Ask how to get from A to B. "How I go reach Yaba from Ikotun?" works just as well as "How do I get from Ikotun to Yaba?" ("How I go reach..." is Pidgin for "How do I get to...").
Get numbered steps: where to board, what the conductor shouts, where to get off, which landmarks to look for, and a fare range.
Save your places (Home, Work, Church) once, then just ask "Take me go work."
Add a route you know. Every trip someone shares makes the app better for the next person.
How it gets people off the screen
OyaGo is designed to be the shortest part of your trip. You spend thirty seconds reading the steps at the bus stop, then you put the phone away and go. The goal is confidence: if you know how to get there, you're far more likely to go to the market across town, visit a friend on the mainland, or finally go to the beach.
Demo
π Live app: https://oyago-web.onrender.com
Code
https://github.com/Kingsmichaei/oyago.git
How I Built It
The architecture
Phone (React PWA)
β "How I go reach Yaba from Ikotun?"
βΌ
FastAPI backend
β 1. Fetch the user's saved places (Backboard memory)
β 2. Send the question + places to the model
βΌ
Backboard
β 3. Retrieve the matching route notes (RAG over the route documents)
β 4. Open-weight model writes the answer, grounded in those notes
βΌ
Numbered, landmark-based directions back on the phone
The open-source AI at the core
Model: Gemma, Google's open-weight model gemma-3-27b-it, served through [Backboard / OpenRouter]. It turns route notes into clear directions and replies in the user's own style: Pidgin if you wrote in Pidgin, plain English otherwise.
Retrieval (RAG) through Backboard. The model doesn't "know" Lagos bus routes, and I didn't want it guessing. Wrong directions in a real city are worse than no directions. So every answer is grounded in a route document I wrote from routes I've actually travelled, plus routes the community adds. The system prompt tells the model to use only what it retrieves, and to say "I don't have this route yet" instead of inventing bus stops or fares.
Memory through Backboard. Each user gets their own small memory store for saved places. That's what turns "take me go work" into a real trip.
The rest of the stack
Backend: Python + FastAPI, structured into config, schemas, services, and thin endpoints. It has a pytest suite that mocks Backboard, so every endpoint and failure case (model down, memory down, missing config) is tested without spending API credits.
Frontend: React + Vite + Tailwind CSS, built as an installable PWA. The design borrows from the danfo itself: yellow with a black stripe, and big touch targets for one-handed use at a crowded bus stop.
Hosting: Both services deploy to Render from a single render.yaml blueprint.
A constraint that shaped the build
I built this on a 2011 HP ProBook laptop. Running a model locally on it wasn't realistic, so I used a hosted open-weight model while developing. That turned out to be a good test of the "open" promise: nothing in OyaGo depends on that particular host. More on that below.
Why Does Open Innovation Matter?
The knowledge belongs to the community, not a platform. The most valuable part of OyaGo isn't the code or the model. It's the route knowledge that lives in Lagosians' heads. Keeping it in plain, open documents means no company can lock it away, change the terms, or switch it off.
I can change the model without rebuilding the app. The model is one line of configuration. Because Gemma's weights are open, the exact same model can run on a hosted API today, on a cheap GPU server tomorrow, or fully offline on a phone or laptop in the future. With a closed API, I'd be one pricing change or a regional restriction away from losing the core of the product.
It can be taught to speak like Lagos. Open weights mean I can fine-tune the model on real Lagos directions (landmarks, conductor calls, Pidgin) so it sounds like a local instead of a translated tourist guide. Closed models rarely allow that level of control. This is the next thing I want to build.
Cost matters here. Many of the people this is for are students and young workers watching every naira. An app that's cheap to run can stay free to use. Open models make that realistic.
Offline is the real goal. Mobile data is expensive in Nigeria and signal drops at the worst moments. A small open model running on the phone, with route notes cached locally, could give directions with no connection at all. A closed API can never do that.
What's Next
Honest limitations, and where I'd take it:
Route verification. Community routes currently go live immediately. Next I'll add a review step so a route needs confirmation before the AI uses it.
Fine-tuning a small open model on Lagos-style directions, then comparing it with the base model.
Offline mode, running a small open model on the device.
More cities. Accra, Nairobi, and many other cities run on informal transport that no map understands. The approach transfers directly.
Prize Categories
Best Use of Backboard: RAG over community route documents, plus per-user memory for saved places
Best Use of Gemma: the open-weight model behind every answer [only keep this if you used Gemma]
Best Use of Render: frontend and API both deployed from one render.yaml blueprint
Thanks for reading! If you've ever been lost in a city where the map app didn't help, I'd love to hear about it in the comments. And if you know Lagos routes, come and add one. π__



Top comments (1)
I would love feedbacks βΊοΈ