What Happens When You Teach Coding Without WiFi? Lessons From a Douala Bootcamp

Where's the WiFi box?

If you ask someone to picture a coding bootcamp, they will probably imagine blazing fast internet, rows of expensive laptops, and a classroom where everything works exactly as planned. Every student downloads what they need in seconds, the projector behaves itself, and somebody says "let's deploy our website" as if that is the easiest thing in the world.

Our July 2026 bootcamp in Douala was different. Seven students aged 7 to 16, five weeks of Mondays and Wednesdays at Olive Bilingual School in Bonaberi, and eight live applications by the end of it.

One morning we arrived at class, unpacked everything, switched on the laptops and got ready to start. Then somebody asked a simple question.

"Where's the WiFi box?"

Silence.

It turned out the WiFi box was not in the classroom. It was sitting comfortably at someone's house, completely unaware that it had an important role in a coding bootcamp that morning.

For about thirty seconds we considered our options. Then someone pulled out a phone, turned on a hotspot, and we got to work.

Sharing one hotspot with an entire classroom

Sharing a phone hotspot with a full class is an experience we can only describe as optimistic. It teaches patience faster than any mindfulness app ever could. Students took turns downloading what they needed while everyone else kept working, installations happened one laptop at a time, and somehow the room never lost its momentum.

The funny thing is that the students barely cared.

Adults tend to panic when technology stops working. Children usually look at you for about five seconds before asking, "So... what are we building today?"

That question tells you everything you need to know. The internet is useful. Curiosity is essential.

The blackout that became a project

A few days later, the electricity disappeared. If you live in Cameroon, that sentence probably did not surprise you.

There was no dramatic reaction. The lights went out, somebody sighed, and we simply changed what we were doing. Instead of writing code, we started talking about ideas. Students sketched interfaces on paper, discussed features they wanted to build, and argued about colours, layouts and user experience. One conversation drifted into the reality of power cuts and how frustrating they are when you are trying to study or finish homework.

That discussion eventually inspired PowerPlan, an application that builds a study schedule around the hours you actually have electricity, with reminders that work around the blackout instead of pretending it will not happen. [link PowerPlan]

It turns out that sometimes the best software ideas arrive when the computers are not even switched on. The same thing produced RouteClaire, built after a conversation about roads that flood in the rainy season and the journeys people take before finding out. [link RouteClaire]

Git does not need the internet

One assumption people often make is that teaching Git and GitHub requires constant internet access. It does not.

Git was designed to work locally. That is the entire point of it. Our students learned how repositories work, why commits matter, how version history protects your work, and what happens when you accidentally break something. They committed changes throughout the week and pushed everything to GitHub once they had a stable connection again.

In many ways they understood version control better because they experienced it before the cloud entered the picture. Most beginners never learn the difference between Git on their machine and GitHub in the cloud, because they never experience the gap between the two.

Publishing turned out to be just as forgiving. Pushing code moves kilobytes of plain text, and enabling GitHub Pages is a few page loads in a settings menu. The entire class going live used less data than one music video. We rotated two students at a time onto the hotspot while everyone else kept polishing offline, and the whole room watched each application appear on the projector one by one.

Eight applications. One phone.

Rationing artificial intelligence

Here is a limit we did not choose but ended up grateful for.

Our students share one organisational account for GitHub Copilot, and the free tier gives that account a fixed number of AI requests each month across everybody. Seven students cannot each prompt fifty times. There is simply not enough to go around.

So we changed the rule. Each student got one shot. They spent an entire session writing a single detailed prompt that specified the application, its three core features, the technical rules, the colour scheme, the file structure, and one crucial instruction: put all the content directly in the code so it can be edited by hand later. Then they fired it once and lived with what came back.

Everything after that was theirs. Reading the code, understanding it, fixing what broke, rewriting the content, adjusting the styling.

We have seen students elsewhere with unlimited AI access who never learn to read code at all, because there is always another prompt available. Scarcity forced ours to slow down and understand what they had been given. If we had unlimited credits, we would have taught worse.

Artificial intelligence had its comic moments too. We deliberately asked Gemini about an award that has not happened yet, and it confidently invented a winner, a film and a director without the slightest hesitation. The classroom burst into laughter, and it was the perfect lesson. Technology can be incredibly powerful, but confidence and correctness are not the same thing.

What we actually remember

Looking back, we do not remember the missing WiFi box as a problem.

We remember students gathering around a single screen because someone's website had finally gone live. We remember the excitement when a stubborn JavaScript bug disappeared after thirty minutes of debugging. We remember students helping each other without being asked, celebrating each other's progress as though every success belonged to the whole room.

Those are the moments that define a classroom.

There is a tendency to think innovation only happens where resources are abundant. Spend enough time teaching young people in Cameroon and that idea quickly falls apart. Give them the opportunity, the right guidance and a chance to build something that matters, and they will surprise you every single time.

Would we like faster internet? Absolutely. Would more laptops make life easier? Without question. Would uninterrupted electricity be nice? Very.

But those things determine how convenient teaching becomes. They do not determine whether young people are capable of learning.

By the end of the bootcamp every student had published a live website. They had learned HTML, CSS, JavaScript, Git, GitHub, Canva, AI and the fundamentals of modern web development. More importantly, they left believing something many of them had never believed before.

They could build technology.

The forgotten WiFi box eventually made its way back to the classroom. By then, it had already missed the best part.

Read what the students actually built during the July 2026 bootcamp. [link to bootcamp recap article]

About Giiyo Tech

Giiyo Tech is a nonprofit based in Douala, Cameroon, delivering hands-on STEM and coding education to children and teenagers. Since 2024 we have reached over 500 learners across 5 schools in 5 regions through bootcamps, school programmes and community workshops.

Visit giiyotech.com or email hello@giiyotech.com.