The 24 Hour Hackathon might go extinct. I hope it survives.

A couple of weekends ago, Bangalore witnessed two important hackathons. Devfolio's Build India (Anthropic x Replit x LightSpeed) and Google's Gemini 3 Hackathon. Build India had a hacking time of about 7 hours, and Google's hackathon was only a bit longer. But hackathons have traditionally been 24 hour sprints - where participants build overnight before pitching to a jury. Why did the time format change?

On the surface, this short format 'hack-day' makes more sense than ever - GenAI tools are very powerful and can spit out prototypes within minutes, so what do you need 24 hours for anyway? from the organizers perspective, its a very attractive proposition – Less costs on food, venue rent and less worry about ensuring security at an overnight venue. Most office spaces and university lecture halls aren't open overnight, so making a hackathon possible always takes extra work.

From a participants' perspective it makes sense too - you don't have to commit an entire weekend, just one day. You don't have to stay up all night. It doesn't wreck your sleep cycle.

Then why am I advocating for keeping the 24 hour format? And why do I care?

I've been involved with Hackathons since 2018. Over 8 years I've participated, won, organized, mentored and judged at over 60-70 of them. I've seen them evolve from students struggling to string together a mostly static webpage, to when online hackathons really took off during the COVID-19 pandemic. Since the last 3 years, I've been involved in being an AICTE mentor and a pre-screening evaluator for Smart India Hackathon, the largest Hackathon in the world. Much like how cricket can be a very different game based on whether its a test match, ODI or T20, Hackathons over very different value propositions based on their length.

24 hour hackathons versus shorter 'hack-days'

Information Asymmetry

A 7-8 Hour Hack-day massively favors more experienced teams or those who know exactly what to build. You might ask why this is a bad thing. Often, more experienced teams do better not just because they are better at building and pitching, but because they have an information advantage that newbie teams don't have. In very domain centric hackathons (like web3, systems, sponsored-tracks etc.), the teams that have participated before know about APIs, frameworks and expectations of the judges. 24 hours is enough for most teams to overcome this knowledge gap and build the best version of their product.

More time to FAFO (Fuck Around and Find Out)

A 24 hour hackathon gives you enough time to start building the wrong thing, fail miserably, turn around and still come out on top. This ability to recover from setbacks is one of the most important lessons anyone can learn as an engineer. 24 hour hackathons often feature multiple rounds of mentoring, which gives teams time to sharpen their pitch, pivot, regroup and rebuild. In a 7 hour hack-day, there's no room for mistakes. You have to walk in knowing exactly what to build, and you'd better hope that your vision matches the jury's idea. If it doesn't, tough luck.

Iterating

Now that GenAI tools spit out prototypes really fast, you can do things that you couldn't in 24 hours. You can deploy your product and get actual user feedback. You can build a V2, V3, V4 and beyond, stopping only when your users have nothing left to criticize. You can build out more features. You can test your solution more thoroughly. You can make more impressive demos. Or if you don't want to do any of those things, you can just hang out with your friends over cups of coffee and pizza.

A Hackathon is not just about building

When my friends and I think back about our experiences, we often remember the late night banter, networking with random people over food, taking walks at midnight, jamming to music and having extended conversations with mentors and jury. These are as much a part of the hackathon experience as the building and pitching itself. Shorter sprints take all this fun out of the event because there's simply no time. It makes event less fun.

Just the right amount of commitment

The opposite of a hack-day is a multi week online hackathon. While these are great accessibility wise, they are very hard for beginners to commit to. Its very difficult to plan out a project over many weeks with teammates that have conflicting schedules, and from personal experience, most teams that sign up for online hackathons end up not making a submission. Without the environment of a hackathon floor, there simply isn't that much motivation to go and actually finish your project. 24 hours is long enough that you can go in without much preparation and win, while also being short enough that your friends will be ready to travel with you.

That being said, when is a shorter hack-day a good proposition?

• Internal Corporate Environments, where participants are older, have more experience and have a level playing field.
• When your college/department has never organized a hackathon before and you want to convince management by doing a shorter hackday successfully.
• When your hackathon does not target beginners at all. Experienced hackers are often busy and appreciate the shorter time frame.

For a college student new to software development, a hackathon is still one of the best ways to explore new technology, sharpen their building skills and to gain valuable insights from more experienced people. With the advent of GenAI, hackathons are less about raw programming ability than before, but they can still teach valuable skills and serve as platforms to network. I hope the 24 hour hackathon survives and thrives.