What 48 hours
actually taught me.

At the end of October I joined roughly 100 Zambian builders for the GreenCode Hackathon in Lusaka, organised by Garage48 and BongoHive with ESTDEV. Two days later, six teams were selected for follow-on support. Ours was one of them. This is the honest version of how that happened, because the useful part of a hackathon is never the certificate.

The brief arrived before the idea did

Hackathon briefs are usually broad on purpose. Ours pointed at green technology and left the problem open. That is harder than it sounds: with forty-eight hours on the clock, choosing the wrong problem costs you a full day before you write a line of code.

We went looking for something that already hurts people in a measurable way, and found water.

Non-revenue water is water that is treated and pumped but never paid for, lost to leaks, theft or metering failures. Nationally it sits at roughly 57% in NWASCO's 2023 sector reporting, with utilities targeting a figure closer to 34%. In plain terms: more than half of the water a utility produces does not earn. Meanwhile communities experience the other side of that same number as dry taps and unexplained bills.

That gap is not a technology problem. It is an information problem. Nobody can act on a leak they cannot see, and nobody trusts a bill they cannot check.

What we decided to build

SmartWater Zambia is one platform with three faces:

• An ESP32 sensor at the tank, reporting level and flow so an operator can see supply in something close to real time.
• An operator dashboard that streams live readings, flags abnormal consumption and shows the network on a map.
• A native Android app where a resident reports a leak, a dry tap or a burst pipe, and tracks what happened to that report.

The logic was simple: give the utility visibility, and give the community a channel. A leak reported by a resident at 7am is cheaper to fix than one discovered by a crew three weeks later.

Where we were honest, and why it helped

We had one real sensor and a working dashboard. The other tanks on screen were simulated, and we labelled them as simulated on the interface itself. TANK_001 was the physical unit, the rest carried a clear demo marker.

That decision felt risky in the moment. Judges have seen a hundred prototypes with fake data. But in a room full of technical people, the team that says “this part is real, this part is simulated, and here is exactly what it would take to make it real” is the team they can actually back. Overclaiming does not survive the first question.

What 48 hours does to a feature list

By the second morning we had more ideas than hours. The cut list was the most valuable document we produced. Anything that did not make the demo clearer came out: no accounts and roles, no historical analytics beyond the live window, no second sensor type. What stayed had to earn its place in a three-minute pitch.

It is the same discipline I now use on paid work, just compressed: decide what the story is, then build only what the story needs, then test the failure paths that would embarrass you live.

The pitch is a story, not a feature list

We opened with a household whose taps run dry while the utility reports losses it cannot locate. Then we showed the same problem as two screens: the operator's live view, and the resident's report. Only after that did we talk about ESP32s and server-sent events.

The order matters. Nobody remembers your stack. People remember the moment they understood the problem.

Top six, and what it means

Being selected among the six winning teams out of roughly 100 builders earned the team follow-on support from Garage48 and BongoHive and a share of the €6,000 award fund. It does not mean SmartWater Zambia is finished. It means a group of people who know this space think the direction is worth a second look.

What I took from it is narrower and more useful than a trophy: a working prototype in forty-eight hours, a team that shipped under pressure, and proof that I can stand in front of judges and defend a build.

What I would do differently

• Test the hardware on hour one, not hour ten. Every hour of sensor debugging cost us a feature later.
• Cut one more feature than felt comfortable. We still had a screen in the demo that added polish but no argument.
• Rehearse the pitch five times. We rehearsed twice. The third run is where the words stop getting in the way.

The full build, including the architecture, screenshots and the parts we deliberately left out, is in the SmartWater Zambia case study. If you are building something at the edge of hardware and community data in Zambia, I would like to hear about it.

Written by Leo Mabuku · Computer Science graduate, currently an IoT intern at CodeAlpha · Get in touch