It was 3:00 AM. Our main sensor node had just stopped transmitting. We had 5 hours until the final judging round. This is the reality of the Smart India Hackathon — it's not about the code you write in the first 30 hours, it's about how you handle the crisis in the last 6.
1. The Problem Statement
PS ID: 1289 - Smart Irrigation for Water Conservation.
The goal was simple: Build a system that auto-irrigates fields based on soil moisture. But the catch was doing it affordably and offline for Indian farmers.
2. Strategy: Scale Down to Scale Up
Most teams tried to build everything — a mobile app, a drone, a blockchain marketplace. We did the opposite. We focused on one thing perfectly: The Soil-to-Pump feedback loop.
The Winning Pitch
"Judges, we didn't build a fancy app. We built a system that saves water even when the internet is down."
3. The 36-Hour Sprint
- Hours 0-6 (Brainstorming): Whiteboarding the "Star Topology" with LoRa. We decided to ditch Wi-Fi immediately.
- Hours 6-18 (Dev): I handled the Embedded C code (PIC16F). My teammate worked on the Python Flask backend.
- Hours 18-24 (Hell): Integration failed. The GSM module refused to talk to the Cloud due to weak signal in the hackathon hall.
- Hours 24-30 (The Pivot): We made the critical decision to move intelligence to the edge. I rewrote the gateway logic while two teammates built the local SQLite schema.
- Hours 30-34 (Testing): Stress testing the offline-first system. We simulated 100 sensor readings, disconnected the network, and verified local decision-making still worked.
- Hours 34-36 (Polish): Building the demo pitch deck. We rehearsed the "pull the ethernet cable" moment 5 times.
The Architecture Decision Record (ADR)
At Hour 25, we documented our pivot as a formal Architecture Decision Record. This is a practice I now use in every project — it forces you to articulate why you made a decision, not just what you changed.
# ADR-001: Move Decision Logic to Edge Gateway
## Status: ACCEPTED (Hour 25)
## Context
GSM signal in hackathon hall is unreliable (-95 dBm).
Cloud-dependent architecture fails during demo.
## Decision
Move pump control logic from AWS Lambda to local
Raspberry Pi Gateway with SQLite persistence.
Use cloud ONLY for async dashboard sync.
## Consequences
+ System works offline (demo-proof)
+ Reduced latency (local decisions in <100ms)
+ Reduced AWS costs (free tier sufficient)
- Lose real-time cloud monitoring during outages
- Must implement async sync protocol (MQTT + retry)| Factor | Cloud Architecture (Original) | Edge Architecture (Pivot) |
|---|---|---|
| Demo Reliability | Depends on internet | Works offline ✅ |
| Latency | 500ms–2s (round trip) | <100ms (local) |
| Cost | AWS Lambda + IoT Core (~$15/mo) | Free (runs on Pi) |
| Complexity | Lower (serverless) | Higher (local DB + sync) |
| Farmer Adoption | Needs constant internet | Works in zero-connectivity areas ✅ |
4. The Great Pivot (Hour 25)
We realized we couldn't rely on the cloud demo. We made a bold call: Move the Intelligence to the Edge.
Instead of sending data to AWS to decide "Pump ON/OFF", we moved that logic to the Raspberry Pi Gateway itself using a local SQLite database. We only used the cloud for *reporting*, not control. This "Offline-First" pivot is what ultimately won us the prize.
5. The Winning Moment
The judges were skeptical about our "Offline-First" claim during the final Mentoring Round. So, during the demo, I pulled the ethernet cable from our gateway.
The system kept working. The pump turned on when I dipped the sensor in dry sand. The data synced 5 minutes later when I plugged the cable back in. That moment — seeing the judges nod — was when I knew we had won.
Key Takeaways
Focus on Core
Don't build features. Build a solution to the core problem. We won because we did one thing perfectly while others scattered across 5 half-built features.
Demo is King
If it doesn't work in the demo, it doesn't exist. We rehearsed the "pull the cable" moment 5 times. The judges' reaction proved it was worth it.
Pivot Early, Pivot Hard
When your architecture fails under real conditions, don't patch it — redesign it. Our Hour 25 pivot from Cloud to Edge was the single decision that won us the hackathon.
Document Decisions
Write ADRs even in hackathons. The judges asked "why Edge over Cloud?" — having a formal decision record made our answer crisp and credible.
What I Learned
- Hackathons are won by architects, not coders. The teams writing the most code lost. The teams making the best design decisions won.
- Offline-First is not a compromise — it's a feature. In Tier-3 India, internet is the exception, not the rule. Designing for disconnection is designing for reality.
- Hardware hackathons are different. Software can be hot-fixed. A fried sensor node at 3 AM cannot. Always bring spares.
- The "pull the cable" test. If your system survives losing connectivity mid-demo, judges take notice. Reliability > features, every time.
- Team dynamics matter. We assigned clear roles (Embedded, Backend, Frontend, Demo) in Hour 0. Zero overlap, zero conflicts.