DEV Community: Kingsmichaei

OyaGo: Asking for Bus Directions in Lagos, Where No Map Knows the Routes

Kingsmichaei — Fri, 09 Oct 2026 06:38:44 +0000

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. 🚌__

Reviving an Abandoned Django Attendance Tracker: From ModuleNotFound to Production Ready | GitHub Finish-Up-A-Thon

Kingsmichaei — Sun, 07 Jun 2026 00:24:52 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

I revived an abandoned Employee Attendance and Leave Management application. What started as a rushed, barely-functional proof of concept is now a secure, single app Django system with role based authentication, mobile responsive UI, and production ready database configurations. It allows employees to self-manage leave requests and clock in, while giving staff a full dashboard for attendance tracking and exports.

Demo

Github Repository
https://github.com/Kingsmichaei/attendance.git

Live link:
https://attendance-njst.onrender.com/attendance/

The Comeback Story

The Broken "Before" State
When I dusted off this legacy project, it was trapped under a mountain of critical technical debt and architectural fragmentation:
Crashing on Startup: The project split logic unnecessarily between an ⁠accounts⁠ app and an ⁠attendance⁠ app. To make matters worse, a simple filename typo (⁠accounts/url.py⁠ singular instead of ⁠urls.py⁠) and a missing project-level ⁠include⁠ import caused immediate ⁠ModuleNotFoundError⁠ crashes.
Infinite Loops: The application’s routing was caught in a recursive logic trap. The sub-app URLs were trying to include themselves, creating an infinite routing loop that paralyzed the Django server.
Security & Configuration Vulnerabilities: The setup script was a security hazard—featuring a hardcoded ⁠SECRET_KEY⁠, ⁠DEBUG = True⁠ left wide open, completely empty ⁠ALLOWED_HOSTS⁠, and zero environment tracking. On top of that, every single frontend form entirely lacked csrf_token tags, making the application completely vulnerable to cross-site request forgery.
Rigid Database: The data layout was hard-coded exclusively for local SQLite development, making it impossible to scale or run reliably in a production container ecosystem.

The Transformation Arc

I decided to execute a complete architectural pivot and code overhaul to transform this project into a secure, cohesive application:
1 Architectural Consolidation: I gutted the broken dual-app dependency and moved all core entities including the user flows, dashboard access, and tracking metrics directly into a streamlined, single-app setup under ⁠attendance⁠.
2 Environment Isolation: I integrated ⁠python-decouple⁠ to completely isolate application secrets. The application settings now dynamically assess the runtime environment: executing on lightweight local SQLite files when ⁠DEBUG=True⁠ and effortlessly scaling out to a robust production PostgreSQL cluster when ⁠DEBUG=False⁠.
3 Ironclad Access Control & Security: I systematically refactored the URL configurations to be completely linear, explicit, and non-recursive. Every single user facing form now contains explicit CSRF protection, and user logout routes are strictly bound to secure POST methods. I isolated public kiosk views entirely away from sensitive staff management views using explicit role checks.
4 Feature Expansion & Responsive UI: I introduced an entirely new ⁠LeaveRequest⁠ data layer to support self-service employee leave management alongside regular clock-in tasks. Finally, the interface received a major design upgrade—featuring data layouts adapted for small screens and an interactive mobile navigation engine powered by a sleek glassmorphic hamburger dropdown menu.

My Experience with GitHub Copilot

My Experience with GitHub Copilot
GitHub Copilot was an invaluable asset during this intense refactoring process, acting as an agile pair programmer that significantly accelerated the path to completion.
Smashed Through Debugging Blocks
The absolute highlight of working with Copilot was diagnosing the broken legacy routing configuration. When I was tracking down why the server was locking up on launch, Copilot instantly highlighted the recursive dependency in ⁠attendance/urls.py⁠ and provided the clean, linear Django path code to resolve the circular loop. It also immediately picked up on the singular ⁠url.py⁠ naming mismatch across the workspace, saving me hours of tracking down obscure traceback logs.
Effortless Configuration Boilerplate
Switching an entire application from standard hardcoded settings to environment variables using ⁠python-decouple⁠ usually requires a lot of tedious copy pasting. Copilot predicted my implementation pattern perfectly. The second I imported ⁠config⁠ from decouple into ⁠settings.py⁠, Copilot automatically suggested the complete, production-hardened variable fallbacks for my PostgreSQL configuration, database credentials, and dynamic ⁠ALLOWED_HOSTS⁠ listings.

Rapid Prototyping for Front-End Interactions
Writing standard vanilla JavaScript to toggle navigation containers and handle UI transitions can be repetitive. Copilot helped draft the event listeners and class-toggling scripts required for the mobile hamburger navigation bar. It let me focus entirely on refining the CSS glassmorphism styles and layout responsiveness, while it quietly handled the structural element selectors behind the scenes.