{"id":449,"date":"2026-08-22T00:39:05","date_gmt":"2026-08-21T19:09:05","guid":{"rendered":"https:\/\/blogs.reskilll.com\/what-i-learned-building-under-pressure-sih-winners-honest-retrospective\/"},"modified":"2026-08-22T00:39:05","modified_gmt":"2026-08-21T19:09:05","slug":"what-i-learned-building-under-pressure-sih-winners-honest-retrospective","status":"publish","type":"post","link":"https:\/\/blogs.reskilll.com\/what-i-learned-building-under-pressure-sih-winners-honest-retrospective\/","title":{"rendered":"What I Learned Building Under Pressure at SIH: A Winner’s Honest Retrospective"},"content":{"rendered":"

Winning SIH didn’t teach me to code better. It taught me to decide faster, cut scope ruthlessly, and communicate clearly under exhaustion.<\/strong> These are the real lessons – the ones nobody puts in their LinkedIn post.<\/p>\n

Lesson 1: The Team That Decides Fastest Wins<\/h2>\n

At hour 0, every team has unlimited potential. At hour 6, the teams that haven’t decided their approach are already losing. We watched it happen around us.<\/p>\n

One team near us spent 4 hours debating React vs Vue. Four hours.<\/strong> On a 36-hour hackathon. They could have built the entire frontend in that time with either framework.<\/p>\n

Our rule: any decision that takes more than 10 minutes gets decided by one person (the team lead) and we move on.<\/strong> Wrong decisions can be fixed. No decision kills momentum.<\/p>\n

Lesson 2: Scope is Your Enemy<\/h2>\n

Our original idea had 7 features. We shipped 2. And we won.<\/p>\n

Here’s what happened: we listed all features, then asked one question for each: “Does the judge NEED to see this to understand our solution?” If no, we cut it. Ruthlessly.<\/p>\n

The 2 features we kept were polished, tested, and worked flawlessly.<\/strong> The team that won second place had 5 features – 3 of which crashed during demo. Judges remember crashes.<\/p>\n

Rule: Build 2 features perfectly rather than 5 features badly.<\/strong><\/p>\n

Lesson 3: The 3 AM Skill – Knowing When to Simplify<\/h2>\n

At 3 AM, your brain tells you to push through the complex solution. To make the ML model work. To add that extra integration. To debug that edge case for 2 more hours.<\/p>\n

Wrong.<\/strong> At 3 AM, the correct move is almost always to simplify. Replace the ML model with a rule-based fallback. Hardcode the edge case. Use a simpler integration.<\/p>\n

Why? Because at 3 AM you’re making mistakes you won’t catch. Every complex line of code written at 3 AM creates two bugs you’ll discover at 9 AM during the demo.<\/p>\n

We made this mistake once: spent 3 hours at night trying to integrate a third-party API. At 6 AM we realized we could simulate the same result with 20 lines of code. Those 3 hours were wasted.<\/p>\n

Lesson 4: Judges Don’t Read Code<\/h2>\n

I spent an embarrassing amount of time refactoring code to be “clean” during the hackathon. Nobody ever looked at it. Not once.<\/p>\n

What judges looked at:<\/p>\n