I won the Smart India Hackathon. Not because we had the best code – because we solved the actual problem while everyone else built impressive tech that missed the point. Here’s the full story, what went wrong, what went right, and what I’d do differently.
How It Started (3 Months Before the Finale)
Our college had 40+ teams registering for the internal hackathon. We needed to be in the top 3 to get nominated. The odds felt terrible.
Our first mistake: we picked the most popular problem statement. Healthcare. AI diagnostics. Everyone picked it. We were competing against 15 teams internally for the same problem.
The pivot that saved us: Two weeks before the internal round, we switched to a less glamorous problem – workflow automation for a government department. Only 2 other teams in our college picked it. Suddenly our odds went from 1-in-15 to 1-in-3.
Clearing the Internal Round
Here’s what most teams did at our internal hackathon: showed slides. Beautiful PPTs with mockups and future roadmaps.
Here’s what we did: showed a working demo. Basic. Ugly. But it actually worked. You could input data and see output. The SPOC told us later that we were the only team with a functioning prototype at the internal stage.
Lesson: A working ugly prototype beats a beautiful non-working presentation at every stage of SIH.
The 36-Hour Grand Finale
Hours 0-4: The Panic
We arrived at the nodal center. Saw other teams. They looked more prepared. Better laptops. Matching t-shirts. We panicked internally.
Then the clock started and something shifted. Half those impressive-looking teams spent the first 2 hours arguing about their architecture. We already had our architecture decided weeks ago. We started coding at hour 1.
Hours 4-16: The Build Sprint
We split the work cleanly:
- Two people on backend + database
- Two people on frontend + UI
- One person on the AI/ML component
- One person on documentation + testing + demo preparation
The person doing documentation sounds useless, right? They were our secret weapon. While everyone else scrambled to prepare their demo at hour 34, ours was already being practiced at hour 20.
Hours 16-24: The Crisis
At 3 AM, our AI model wasn’t giving accurate results. The training data was insufficient. We had two options: spend 8 hours fixing it, or simplify.
We simplified. Instead of a complex ML model, we used a rule-based system with an LLM API for the parts that needed intelligence. It worked. It was accurate. Judges never asked if it was “real ML” – they asked if it solved the problem.
Lesson: Judges evaluate the solution, not the complexity of your implementation.
Hours 24-36: The Polish
By hour 24, our core was working. Most teams were still debugging basic functionality. We spent the last 12 hours on:
- Error handling (what happens with wrong input?)
- Realistic test data (Indian names, actual addresses, real scenarios)
- Mobile responsiveness (judges checked on their phones)
- A 3-minute demo script (practiced 5 times)
- Backup: recorded video of the demo in case live crashed
The Demo That Won
Our demo was 3 minutes. Not a second more. We showed:
- The problem (10 seconds – one statistic)
- Our solution working live (90 seconds – real data flowing through)
- The impact (20 seconds – “saves X hours per week for Y department”)
- Technical depth (20 seconds – architecture diagram, one slide)
- Scale (10 seconds – “can handle 10,000 concurrent users”)
The team next to us had a 12-minute presentation. Judges cut them off at 5. They were still explaining their architecture when time ran out. Never showed a working demo.
What Actually Won It (The Judge’s Feedback)
After winning, one judge told us specifically:
- “Your solution actually addressed the problem statement. Most teams built something adjacent.”
- “The live demo with real data made us trust it works.”
- “You clearly tested edge cases – the error handling was impressive.”
Notice: they didn’t mention our code quality, our ML model accuracy, or our tech stack. They mentioned problem fit, working demo, and robustness.
What I’d Do Differently
- Start the prototype earlier – we started 2 weeks before internal round. Should have started 4 weeks.
- Talk to actual users – we assumed what the government department needed. A 10-minute call would have given us insights others didn’t have.
- Sleep strategy – we all stayed awake 36 hours. By hour 30 we were making stupid bugs. A rotation sleep schedule (2 people sleep 4 hours while others work) would have been smarter.
The Aftermath
Winning SIH opened doors we didn’t expect: internship offers from two companies who saw our demo, a feature in our college newsletter, and confidence that we could build real things under pressure.
But the biggest win wasn’t the prize. It was learning that the simplest solution that actually works beats the most complex solution that almost works. That lesson applies everywhere – jobs, startups, life.
Start Your SIH Journey
SIH 2026 has launched. 226 problem statements are live on sih.gov.in. If you’re reading this, you still have time to prepare.