Verge is the annual technical festival of SRM University Delhi-NCR at Sonepat, Haryana, and SRM Builds 7.0 is its flagship hackathon. This year it ran for a punishing but exhilarating 36 hours, and I was invited to join as a mentor. Anyone who has done a 36-hour hackathon on either side of the table will tell you: the twelve extra hours over a standard 24-hour format completely changes the character of the event. Teams stop hacking and start building.
Picture below is from the closing ceremony, holding the certificate of appreciation with one of my co-mentors. It's easy to forget these moments happen — you spend so much of a hackathon walking laps around the hall that the awards feel almost anti-climactic. But looking back, this one meant a lot.
The mentor lineup
The mentor bench at SRM Builds 7.0 was ridiculously good, and I say that as someone who is usually the youngest person in these rooms. Sharing the mentor role with me were Uday Sharma, Saurav Dutta, Nimarpreet Singh, and Parul Garg — engineers and product folks whose feedback I found myself learning from between sessions. If you're a hackathon organizer reading this, the quality of your mentor lineup is the single biggest lever you have on team output. SRM absolutely nailed it.
Why 36 hours changes the game
In a 24-hour hackathon, you're essentially building a rough proof of concept and a shiny demo path. In 36 hours, teams have enough time to hit a real wall, walk away from it, and come back with a better design. That inflection point — usually around hour 20 — is where mentoring becomes valuable in a completely different way. Instead of debugging syntax, you're helping teams choose which of their two prototypes to throw away.
- Hour 0–6: idea validation, scope trimming, and (in most cases) convincing teams to build one thing well.
- Hour 6–20: execution mode. Mentors mostly stay out of the way and answer specific technical questions.
- Hour 20–30: the interesting phase. Teams have working code and are now deciding what to cut, what to polish, and how to demo.
- Hour 30–36: dry runs, video recording, slide cleanup, and the frantic race to make the README not embarrassing.
The teams at SRM Builds 7.0 mostly used hours 20–30 the way you want them to be used — questioning their own assumptions and killing features. That is not a coincidence; it is a direct consequence of a mentor lineup that pushed them to.
Standout projects
Without naming specific teams (some are still working on turning their hacks into products), a few themes stood out. There was a lot of thoughtful work in the AI-agent space — not the shallow 'wrap-a-prompt-in-a-UI' type, but genuinely stitched-together workflows with real retrieval, memory, and evaluation loops. Two teams built assistive-tech projects with obvious care for the end user. And one team shipped a distributed-systems demo that would have made a decent conference talk.
The best sign of a well-run hackathon is that even the projects that did not win were interesting. That was the case here.
The organizing team
SRM's student council ran a genuinely polished event. The venue signage, the mentor scheduling, the check-in flow, and the branding were all a step above what I usually see at university hackathons. The Verge organizing team clearly treats the fest as a product they iterate on year over year — you can feel the compounding institutional knowledge in the details.
A hackathon is not a one-time event. It's a codebase that student teams inherit and refactor each year. Verge 26 is on version 26, and it shows.
The 3 AM conversations
The most valuable part of any hackathon, for me, isn't the mentor rounds or the closing ceremony. It's the 3 AM conversations in the mentor lounge with the other mentors. When a group of people who love this work sit around a table with bad coffee at three in the morning and start comparing notes on how they'd have architected a team's project — that's where you actually learn things. Thanks Uday, Saurav, Nimarpreet, and Parul for those conversations.
Wrapping up
SRM University Sonepat has quietly built one of the better hackathon franchises in North India, and Verge / SRM Builds 7.0 is a big reason why. Huge thanks to the entire student organizing council for the invite, to the faculty coordinators for backing the event with real institutional support, and to the four mentors I shared the panel with.
If SRM Builds 8.0 rolls around next year and my calendar is open, I'll be there. Bring the coffee.