Afterschool Geekery Uganda Project Manager

Mentor area: course management
Starting screen
Mentor area: session log form
Admin area: course visit
Mentor area: course curriculum
Mentor area: stories of the month

Inspiration

This app was built for a real, ongoing education project, in the Ugandan communities where it will be used, by the very person who created and runs the project.

Afterschool Geekery Uganda teaches coding and robotics to children who have no access to digital education. In fact, these kids have little access to quality education of any kind.

I have run this project for more than a year. I built partnerships, planned courses, taught children, trained mentors, visited sessions, collected evidence, and followed student progress. In a few weeks, after 18 months in rural Uganda, I will return to Europe. The courses will continue. Mentors and administrators will remain in the field. The project cannot depend on my physical presence anymore. The local team needs clear workflow and simple tools. I need reliable information so I can support them from a distance.

This is why I started building the Afterschool Geekery Uganda Project Manager. I built this app alone, in my spare time, while managing the project itself. Development began on July 10, after several weeks of planning. I did not know about OpenAI Build Week.

I first built features one by one with ChatGPT. During the final days, after learning about the hackathon, I moved to Codex CLI. It helped me work faster across the whole codebase, especially with testing, larger changes, and refactoring.

What the app does

The app helps the Ugandan team run the project without depending on one person being present. It manages mentors, courses, students, session records, photos, field stories, and progress data across several locations.

Mentors can see their assigned courses, submit session logs, record attendance and learning activities, upload photos, review earlier sessions, submit and rate field stories, and open the curriculum.

Administrators can manage courses, mentors, and students. They can review logs and photos, inspect student records, monitor attendance and progress, record course visits, and select monthly field stories.

These roles come along with strict boundaries. Mentors only see the courses assigned to them. Administrators can see the wider program. Users do not have access to sensitive, identifiable participant data.

Planned features include skill surveys, invoices, course reports, project reports, statistics, and integration with skill-building games.

The app is built for Afterschool Geekery Uganda, but hopefully the system can later be adapted for similar education projects. The backend can already support mentors working in several countries, a multilingual interface.

How I built the app

The app has a Flutter frontend and a FastAPI backend. It uses SQLite and a REST API.

Before coding, I defined the main parts of the system and how they relate to each other. These include accounts, mentors, courses, students, attendance, session logs, projects, photos, stories, ratings, course visits, and student records.

With ChatGPT, I developed features through the full stack. This included database models, validation, endpoints, tests, frontend models, API calls, controllers, screens, routing, and frontend tests.

I made the decisions about the project rules, the structure of the app, privacy, permissions, and what mentors could realistically be asked to do.

Codex CLI helped most when the work crossed many files. I used it to inspect patterns, standardise the code, extract shared widgets, check permissions, fix inconsistencies, and run tests.

The backend and frontend now have more than one hundred automated tests between them. I have also tested complete mentor and administrator workflows.

Challenges

The main challenge was not technical. It was building software while running the project the software is meant to support.

I worked mostly after hours, on an ageing laptop, in Ugandan villages with weak internet and limited resources. At the same time, I was teaching, travelling, solving daily problems, supporting mentors, keeping the project alive. These conditions slowed development, but they also kept the app close to reality.

I know what a mentor can enter after a long teaching session. I know which forms create work without producing useful information. I know that many users have cheap smartphones, small screens, and very limited mobile data.

The hardest design problem was deciding how much information to collect. A session can include attendance, mentors, projects, learning status, skill games, notes, and photos. The record must be useful, but it must not become another burden on the people doing the real work.

Privacy was another serious concern. The app contains information about children and photos from courses. Access rules must be correct in the database, the API, and the interface.

Speed was also dangerous. AI can produce code faster than a person can properly review it. Without fixed patterns and regular refactoring, the code can become difficult to understand even while it still works.

What I am proud of

The app exists because the project needed it, not because I wanted to build a demo. It is based on active courses, real mentors, real students, and problems that appear every week.

It brings together information that was previously spread across messages, spreadsheets, photos, and memory. Session logs connect attendance, activities, projects, notes, and evidence. Student records show participation and progress. Field stories show the human side of the work.

The app began as a progress tracker. It soon became a wider project management system. Its purpose has not changed though: to understand how efficiently children are learning and how efficiently the program is working.

I am proud that this project is succeeding in a difficult environment. I am proud that local mentors are becoming able to carry more of the work. The software matters because it supports that change. It gives the Ugandan team a real chance to take over daily operations while I continue to support the project from Europe.

What I learned

The most important lesson was that AI does not remove the need for a developer who understands the problem the code is meant to solve.

The human must define the rules, workflows, limits, and priorities. The AI can work quickly, but it does not know the project, the people, or the field unless those things are explained clearly. During development, I had to check assumptions, test behaviour, and reject solutions that did not fit the real work. After rapid development, I had to step back and refactor multiple times.

The worst approach is to keep asking for more features without protecting the structure of the code. The software may still work, but it becomes harder to change and trust.

I also learned that although charities and small NGOs in Africa need digital tools designed for their real conditions, generic business software often assumes more money, better devices, stable internet, and full-time office staff. A field-built app may be less polished than software made by a professional team. But it can understand the work better.

What’s next

The core system works. The next step is to place it in the hands of the people who will use it.

In the coming weeks, I will finish the remaining reporting and administration features, prepare the production server, train mentors and administrators, and begin Google Play testing.

The first updates will come from real use during courses, not from guesses made at a desk.

The goal is not simply to publish an app. It is to help Afterschool Geekery Uganda become locally run, accountable, and able to continue without depending on the program manager being physically present.