My First Hackathon: Building InDisaster
“Technology is best when it brings people together; especially when everything else falls apart.”
Recently I had the chance to take part in my first hackathon, and it’s an experience I won’t forget. Two days of nonstop building, debugging, and rethinking decisions we’d made six hours earlier. In this post I want to walk through what we built; a disaster management app called InDisaster; the problems we ran into, the stack we used, and what I actually took away from the whole thing.
Which Hackathon Was It?
It was Build with Gemma: GDG TIU Buildathon , hosted at our college. It ran over two days; day one was for building, day two was evaluation, presentations, and networking.
The theme was to build something around Gemma, and there were five domains to pick from: Open Innovation, AI for Education, AI for Healthcare, AI for Small Business, and AI for Travel & Tourism. Our team went with Open Innovation and decided to build something in disaster management.
The Idea: InDisaster
InDisaster is meant to help individuals get relief guidance and send distress messages using on-device AI; no server round-trip required. You describe your situation, and it responds with the most relevant way to stay safe.
The feature we cared about most, though, was that it could send a distress signal even with zero internet connectivity. That turned out to be both the scariest line item on our whiteboard and, ironically, the easiest thing to actually build. More on that below.
The Core AI: From Chatbot to Classifier
Most of the real difficulty in this project lived in getting the on-device AI to behave predictably under hackathon-grade hardware and time constraints.
Challenge 1: Size
Gemma is a large model, and running it on-device means every gigabyte matters, both for storage and for what your phone’s RAM can realistically hold alongside everything else running. Finding a properly quantized build wasn’t trivial, even digging through Hugging Face. I eventually landed on a 4-bit quantized Gemma E2B, around 1.4 GB.
That number looks small next to the RAM in a modern phone, but the reality hit later, once I actually tried to get it running end-to-end on a physical device for testing rather than in a comfortable emulator.
Challenge 2: 4-Bit Quantization Has a Cost
Shrinking the model down that far also shrinks its reasoning ability; practically speaking, closer to a four-year-old than a helpful assistant. Left to freely generate text, it would either parrot back the example in the prompt or produce confident nonsense.
The fix was to stop asking it to generate anything at all. Instead of open-ended text generation, we constrained Gemma to a single job: classify the emergency into one of a fixed set of tags, then let deterministic app logic pick a pre-written response for that tag. No more freeform text, no more repetition loops, no more nonsense; just a single uppercase token like FLASH_FLOOD coming back from the model, which the app then looks up against a local disaster-response catalog to show the person real, pre-vetted steps.
Something like:
<start_of_turn>user
[TASK: EMERGENCY DISASTER CLASSIFIER]
Categorize the incoming user situation into EXACTLY ONE tag from this list:
FLASH_FLOOD, EARTHQUAKE, HOUSE_FIRE, MEDICAL_EMERGENCY, CYCLONE, ...
RULES:
- Output ONLY the single exact tag name in UPPERCASE.
- DO NOT write any introductory text, explanation, or markdown.
User Text: Water is rising fast on the ground floor and the power main is sparking!
<end_of_turn>
<start_of_turn>model
FLASH_FLOODReframing the model as a classifier instead of a chatbot turned out to be the single most important design decision in the whole project. It’s faster, it’s deterministic, and a quantized model that would otherwise ramble is perfectly capable of picking one word from a fixed list.
Tradeoffs
A few compromises we made along the way, mostly forced by hackathon time limits:
- Instead of bundling the model directly into the app, we pushed it onto test devices via
adb, since downloading a 1.4 GB model on-demand during a demo wasn’t something we wanted to risk. - We accepted the classification-only approach as a permanent design choice rather than a stopgap; it’s genuinely more reliable for this use case than trying to coax a small model into freeform generation.
The Fun Part: Getting a Distress Signal Out With No Internet
This ended up being the least stressful part of the build, which surprised both of us going in. Most of the heavy lifting is already done by Google’s own libraries; Android devices can discover and talk to each other over Bluetooth and Wi-Fi Direct without any internet connection at all, and the Nearby Connections API handles discovery, connection, and message delivery between devices out of the box.
Once the AI classifies a situation, the app packages the tag along with the device’s last known GPS coordinates into a small JSON payload:
{
"status": "FLASH_FLOOD",
"user": "Handset_Alpha_91",
"lat": 22.5726,
"lng": 88.3639,
"ts": 1772000000,
"message": "Water is rising fast on the ground floor and the power main is sparking!"
}From there, every phone running InDisaster acts as an ad-hoc relay node. If a device is out of range of any cell tower, it broadcasts that payload to whatever nearby devices it can reach over BLE or Wi-Fi Direct. The message hops from phone to phone across the mesh until one of them reaches an actual network; a rescue team’s hotspot, a satellite uplink, anything; at which point it syncs straight to the backend.
We paired this with a small web dashboard so rescue teams could see incoming signals on a live map as they synced in; markers dropped by category, with a panel filtering for anything received in the last 15 minutes, so the most urgent, most recent signals stayed front and center.
What I Learned
The biggest lesson wasn’t really about disaster response; it was architectural. When you’re building something meant to survive infrastructure failure, you can’t lean on the cloud as your single point of truth. Pushing the actual decision-making (classification, triage, response lookup) onto the device itself, and treating any cloud sync as a bonus rather than a requirement, was what made the “zero internet” pitch actually true instead of aspirational.
The other lesson was smaller but just as useful: constraining a weak model to a narrow, well-defined task will usually beat trying to get more out of it through prompting. We didn’t need Gemma to be smart. We needed it to reliably pick one word out of twenty, and once we accepted that, everything downstream got a lot more predictable.
What’s Next, If worked on more
The hackathon prototype proved the core idea end-to-end; offline classification, mesh relay, and a live map on the other end. A few things I’d want to take further if this continues past the hackathon:
- Fine-tuning a small LoRA adapter on real emergency-response data to improve classification accuracy across dialects and phrasing
- Letting people attach a compressed photo (e.g., of structural damage) to the distress payload for richer triage
- Smarter, geography-aware routing for the mesh hops instead of naive flooding to every nearby device
The Experience
After just 15 mins in the venue it just hit that even if I dont get Deleected for prised just teh experisence Is Enough, i mademore friends and added people to my network. We were given pizza and a bottle of cococ-ola and we were all set to go.
Now the Final Part: The Result
Did i got any prizes? No, Unfortunately, we did not win any prizes. Its ad but sometime its happens. While leaving I asked teh juges the told taht tehy loved out mvpa nd idea but the even was more towards gemma integration, Out products core did not warped the gemma enough, So they chose other teams who had more gemma integration. But the experince was worth it and I learned a lot from this hackathon.