Most first-time hackathon teams optimise for the wrong thing: the most impressive-sounding tech stack instead of the clearest possible demo of a real problem being solved.
Before the hackathon starts
- Pick a problem you or someone on your team has actually experienced, not one that sounds hackathon-friendly.
- Split roles before the clock starts — who owns backend, who owns frontend, who owns the pitch. Deciding this mid-hackathon costs hours.
- Scope down. The version you can finish and demo beats the version you can only describe.
During the build
Working software beats a polished slide deck of a broken feature, every time I've judged or competed. Build the ugly version that works before you make anything look good.
The pitch is a separate skill from the build
I learned this the hard way with STROT — a system that took two days to build, explained in two minutes, and lost because the pitch didn't land, not because the system was weak. Rehearse the pitch as its own deliverable, separately from finishing the code.
What judges actually reward
Can they explain your idea back to you after one pass? Does the demo work live? Did you make a visible, deliberate tradeoff? Those three questions predict a scoreboard better than framework choice ever does.
GenAI engineer and AI product builder with 2+ years shipping production-grade AI systems: RAG pipelines, fine-tuned LLMs, hybrid retrieval and multi-modal apps across vision, speech and OCR, architected end to end from ingestion to deployment. Leads engineering for SCULT INDIA's 14-member team, founded the 500+ member TechVerse Enclave community and has mentored 200+ students. Three hackathon first prizes: Changethon 2025 (IIT Roorkee), Product Genesis at Vividhotsava 2025 (CSJMU Kanpur) and BYTEBATTLE (MeetKats).
Open to GenAI roles, hackathon judging, mentorship sessions and guest talks at colleges. Email pranjulrathour41@gmail.com.
