What a Lost Hackathon Taught Me About Technology

In my second year of advanced level, a teacher sent me a link to an AI Learning Hackathon. It was open to schools across Rwanda, and only ten would be selected. We applied, and while we were sitting our end-of-term exams, we found out we had been chosen.

Walking in unprepared

The event was held in Kigali, with students, tech leaders and people from other countries in the room. Each school sent a team of three. I was the team leader, which meant I was the one who pitched.

On the first day, we did our pitches, and I discovered two things at once. First, our project idea was almost identical to the idea of a team from Rwanda Coding Academy, the school I had once wanted to attend. Second, everyone else had arrived with a finished, working product. We had arrived with an idea.

We had assumed the competition would give us time to build. It didn't. We had misread the format, and nobody had told us because everyone else already knew.

Two days without sleeping

So we built. We spent the last two days working with no rest. We were staying in a hotel, and none of us ever slept in a bed.

We made GuideMe, a personalized learning web app. I handled the backend with Flask and Python, using skills I had picked up from an online Python course. It was the time when ChatGPT and Google's Bard were new, and AI in learning felt like the future.

The demo that didn't run

On the final day, we were exhausted, and I was feeling sick after three days without sleep. During rehearsal I tried to run our prototype and something was wrong. The API key we were using had hit its rate limit from all our testing, and the whole project depended on it.

I kept hoping the problem would fix itself by the time we presented. It didn't. We pitched well, but when it came to the demo there was nothing we could show. We explained it to the judges, and it bought us nothing.

Who won

Three teams were announced as winners. The first place went to a team from a school that doesn't even teach software development. Their project was a simple tool to help blind people use a computer, built with plain HTML. It was not complicated, and it was solid.

That was when I understood something I have not forgotten. The technology you use matters far less than the size of the problem you solve. A simple tool for a problem that really hurts beat our more ambitious AI project that couldn't run.

What I took away

Solve a problem that hurts. I still think about that blind-accessibility tool when I choose what to build. Impressive technology is not the same as useful technology.

Never depend on a single thing you don't control. Our entire demo relied on one external API with no backup. A recorded demo or a fallback would have saved us. Now I think about what happens when the thing I depend on stops working.

Read the format before you arrive. We lost time because we didn't understand the rules. Ask before you assume.

Losing can give you what winning wouldn't. We didn't win, but that weekend gave me something school couldn't: real experience, people in the field, and the first time someone with real experience explained AI to me properly. Every participant also received a new laptop, and I am still working on mine today.

Why it still matters

Almost everything I do now traces back to that room in Kigali. When I say ATAS should be judged by whether it solves real problems in Rwanda, not by how advanced its technology sounds, I am really repeating what that weekend taught me at a cost of three nights of sleep.