The honest story of how a frustrating lecture-download problem at KWASU turned into the most technically challenging project of my life — and what I learned about building for people who are truly underserved.
It started with a 200MB video lecture that took six hours to download.
We were deep into the second semester of second year, and the university's e-learning portal had just been updated with a new batch of recorded lectures for our Data Structures course. Great. Except the campus network was essentially unusable by 9am because hundreds of students were all trying to pull the same files simultaneously.
By the time my laptop finished downloading, it was past midnight. I'd spent the whole day in the library waiting. Not studying. Waiting. And I was one of the lucky ones — I had a laptop and a reliable enough connection that the download eventually completed. Many of my classmates just gave up and found someone's WhatsApp group where a single student had compressed the video into a grainy 40MB file that looked like it was filmed through a jar of petroleum jelly.
That was the moment I started paying serious attention to the problem.
I started talking to students across different faculties and departments. Same story, different details. Engineering students downloading CAD software packages. Medical students trying to access virtual lab simulations. Law students pulling down case libraries.
The shared theme was always: the content exists, the device exists, the desire to learn exists — but the pipe is broken.
"The most dangerous kind of poverty isn't not having access to content. It's being close enough to touch it but unable to grab it."
Nigeria has 170+ universities. A significant portion are in cities where 4G is unreliable and 5G is nonexistent. The government's answer has been to upgrade campus networks — but that's slow, expensive, and has been "coming soon" for years at many institutions.
I didn't want to wait for the infrastructure to catch up. I wanted to build something that worked with the hardware that already existed in every student's pocket.
My first instinct was an offline-first progressive web app. Download lectures when you have connectivity, consume them offline later. Standard stuff. I built a prototype in about two weeks.
It worked. But it didn't solve the real problem. It still required each student to independently find connectivity and download content. If you lived off-campus, or your device died before you could sync, or you simply didn't know a lecture had been uploaded — you were still stuck.
The insight I was missing was this: the problem isn't individual access, it's collective distribution. On any given campus, a handful of students with decent connectivity are accidentally gatekeeping content from the students around them.
The idea of using Bluetooth for content distribution came from an unlikely source — I was reading about how protest movements in Hong Kong used Bluetooth-based apps like Bridgefy to communicate when the government throttled cellular networks. If Bluetooth could carry protest communications, it could definitely carry lecture PDFs.
I spent two weeks reading everything I could about BLE (Bluetooth Low Energy) — how it works, what its throughput limits are, how Android and iOS handle BLE differently, what background scanning limitations exist on each platform.
BLE is slow. Maximum throughput in ideal conditions is around 250kbps on a single connection. But the key insight is that in a mesh topology, you're not relying on a single connection — you're pipelining data across multiple hops. One device seeds to five nearby devices simultaneously, each of which becomes a seed node for the next five.
I got a lot wrong initially. The list is long:
Each of these failures cost me weeks. But I kept going, because every time I showed a working version to a student who actually needed it — watching their face when a video loaded without them having to hunt for connectivity — I felt the pull of the problem too strongly to quit.
MeshLearn is in closed beta with about 60 students at KWASU across three departments. The BLE mesh is stable. Content propagation works. The ML recommendation engine is live but still rough around the edges.
The most surprising result of the beta has been the social dynamics it creates. Students have started forming informal study groups around the app — they meet physically because the mesh works best when devices are in close proximity, and those in-person meetings have been more effective than anything a digital tool alone could engineer.
Sometimes the best outcome of a technology is the human behaviour it accidentally enables.
Building MeshLearn taught me that the most important product skill is not knowing how to build things — it's knowing why things are the way they are before you try to change them. I spent months assuming the problem was a technology problem. It's actually a distribution problem, which requires a technology solution — but those are very different framings, and they lead to very different products.
The version of MeshLearn that exists today bears almost no resemblance to the version I imagined in that library at midnight, watching a progress bar crawl. And that's exactly how it should be.
I write about building, design, and engineering from the perspective of someone doing it in West Africa.