My first physical hackathon turned out very differently from what I expected.
Our project, KMesh: Local AI over Mesh Network for Disaster Management, was announced as a Special Winner in the Best Use of Gemma 4 category at the Google DeepMind Hyderabad Hackathon on Kaggle.
The funny part is that we left the venue thinking we probably wouldn't make it into the top 10.
Here's how it happened.
I didn't even know I was going to a hackathon
A couple of days before the Google DeepMind Hyderabad Hackathon, I wasn't planning to attend a hackathon at all.
Then Huzefa bin Juned asked me to check my email. He had registered our team, and suddenly, I had a hackathon to prepare for.
The funny part? We didn't know the theme of the hackathon yet.
The night before the event, we had a team meeting to figure out what we might build. Osama bin Juned suggested that we should be ready to work on an Android app, so he asked us to set up Android Studio.
I already had it installed, but I hadn't used it for quite some time.
Since the event focused on Google's Gemini APIs, I made a basic Android app to test a live Gemini API connection. Nothing fancy, just enough to make sure I could get something running when the actual challenge arrived.
The morning started with an alarm that didn't ring
On the day of the hackathon, I had to wake up early. My alarm didn't ring, but somehow I woke up anyway.
We still reached the venue late. The initial activities had already happened, but we made it before the problem statements were revealed.
Once the challenge was announced, we found our workspace and split up the problem statements among ourselves. Everyone spent around half an hour researching different options. Then we came back together to discuss what we had found.
One idea stood out: Osama's idea around disaster management.
It felt like a problem where technology could make a real difference, especially when people need help and the usual communication infrastructure might not be available.
We agreed to work on it.
The real project was the mobile app
KMesh wasn't just a dashboard. The most important part of our project was the Android mobile app, designed for citizens and responders during a disaster.
Think about a flood or another emergency where internet connectivity is unavailable. Someone needs help, but they can't send a report to a central server.
What if their phone could still save that report and pass it to nearby devices?
That was the idea behind KMesh.
A citizen could compose an SOS message on their phone. The app would save it locally first, so the report wouldn't depend on an immediate internet connection. Nearby phones could then pass messages along through a mesh-style relay system, helping information travel between citizens, relay devices, and responders.
We also integrated Gemma 4 for on-device triage, with the goal of identifying which people appeared to need help most urgently.
During a disaster, responders may receive more requests than they can act on at once. We wanted to explore how local AI could help surface high-priority reports without always waiting for a server response.
The dashboard helped us visualise the wider response workflow, but the core idea was the mobile app and the network connecting people in the field.
How the offline mesh flow worked
The design aimed to keep reports moving even when internet connectivity was unavailable.
Citizen phone
|
| Compose SOS
v
Save locally using Room
|
v
Nearby Connections
(Bluetooth / Wi-Fi Direct)
|
v
Nearby relay phones
|
| Store, deduplicate and relay
| Seen-set + TTL
v
Responder device
|
v
On-device triage with Gemma 4
|
v
Internet becomes available
|
v
Central command + Gemini
|
v
Response relayed back through the mesh
There were a few important design choices behind this flow:
- Save first: An SOS is stored on the device before attempting to send it, reducing the chance of losing a report when connectivity is poor.
- Relay between nearby devices: Phones can pass messages using Bluetooth or Wi-Fi Direct through Nearby Connections instead of requiring every citizen to reach a central server directly.
- Avoid duplicate relays: A seen-set and time-to-live (TTL) help prevent messages from circulating indefinitely.
- Triage on-device: Gemma 4 can help assess incoming reports locally, so prioritisation doesn't always have to wait for a server round trip.
- Sync when possible: When internet access returns, information can reach central command, where Gemini can support the broader workflow. Replies can then be relayed back through the mesh.
The intention was to make emergency communication more resilient, not to assume that every device would always have internet access.
The people behind KMesh
A special thanks to Osama bin Juned, who led our team and introduced the disaster management idea. It gave us a meaningful direction to work toward in a very limited amount of time.
I worked on this with Osama bin Juned, Huzefa bin Juned, and Imran.
Huzefa was the reason I knew about the event in the first place, and I'm glad he reached out. We researched different problem statements, discussed the trade-offs, and worked together to turn the selected idea into a demonstration.
And between the planning, coding, and discussions, there were the usual hackathon moments too: food breaks, coffee, and quick conversations about what to try next.
The judging round, and why we thought it was over
When it was time for judging, a judge came to our workspace. Unfortunately, one of our team members wasn't there at that moment, so we went to the organisers and explained the situation.
They assigned us another judge, who gave us just five minutes to explain the project.
Osama did most of the explaining, and we walked the judge through the idea and gave a demo.
To be honest, the demo didn't go as well as we'd hoped.
We left thinking we probably wouldn't make it into the top 10.
And, as it turned out, we weren't in the top 10. We accepted that and headed back, talking more about how good the experience had been than about the result.
It was our first physical hackathon, and we'd still learned a lot and given the project our best.
Then, a few days later, something unexpected happened.
The message that made our day
The Special Winner announcement came out on Kaggle.
Once again, Huzefa was the one who spotted it and shared the news in our WhatsApp group.
We were genuinely happy and proud. After leaving the venue thinking we'd probably missed out, finding out that KMesh had been recognised as a Special Winner in the Best Use of Gemma 4 category felt amazing.
It meant even more because this was our first hackathon.
We knew the demo hadn't been perfect, but we'd put in the effort, worked together, and tried to solve a problem that mattered.
That recognition reminded me that one imperfect presentation doesn't tell the whole story of the work behind a project.
What I learned
A few things stayed with me:
- Start with the problem. The most useful part of our discussion was deciding which problem was worth solving, not which technology sounded exciting.
- Prepare enough to move quickly. Testing the Gemini API the night before gave me a small head start, even though we didn't know the final challenge.
- Design for real conditions. In disaster response, connectivity may be unreliable and time matters. That changes how you think about saving, relaying, and prioritising information.
- Keep the scope practical. A focused mobile app and a clear demonstration can communicate an idea better than a long list of features.
- Build with people who bring ideas. Osama's direction and the team's discussions helped us turn a broad challenge into a project we could explain and demonstrate.
I'm grateful to Google DeepMind, Kaggle, the organisers, and everyone who made the event possible. I'm especially grateful to Osama, Huzefa, and Imran for being part of this experience.
This was my first physical hackathon, but hopefully not my last.
I want to keep building software products that solve real-world problems, and KMesh was a meaningful step in that direction.
Top comments (0)