The pitch is always the same: "Let's do a hackathon! Two days of pure innovation, no meetings, just building." Then someone asks about rules and the room goes quiet. Then someone asks about judging criteria and three VPs start having a different meeting. Then someone asks whether remote employees can participate and everybody stares at their laptops.
Internal hackathons are one of the few corporate events that people actually want to attend. Developers want to build things without Jira tickets. Designers want to explore ideas without stakeholder reviews. Product managers want to... well, product managers want to manage the hackathon, which you should probably let them do, honestly.
The challenge isn't generating enthusiasm. It's channeling 48 hours of creative energy into something that doesn't collapse under its own ambiguity.
Hackathon Rules That People Actually Follow
Hackathon rules exist on a spectrum from "literally anything goes" to "here's a 12-page requirements document." Both extremes produce bad outcomes. Total freedom means half the teams spend day one arguing about what to build. Over-specification means you're just doing regular work without the regular process, which is worse than regular work with it.
The sweet spot is theme plus constraints. A theme gives direction: "Improve the onboarding experience" or "Build something that solves an internal pain point." Constraints give structure: "Must use our existing tech stack," "Must be demo-able in five minutes," "Teams of 3-5 people." Theme without constraints is chaos. Constraints without theme is a specification.
The rules people actually fight about are the non-obvious ones. Can you start with existing code? (Decide this explicitly or teams will interpret it differently.) Can teams be cross-functional? (Yes. Always yes. Engineer-only teams build technically impressive things nobody can explain in the demo.) Can you work on something related to your regular project? (This is where it gets political. The honest answer is "yes, but the judging should reward novelty.")
Hackathon Judging That Isn't a Popularity Contest
Hackathon judging is where good events go to die. The usual failure mode: three executives who weren't involved in any of the work spend 90 seconds watching each demo, then vote for the team that includes someone they know. Or, worse, they vote for the project most aligned with their team's existing roadmap, turning "innovation day" into "free labor for the product org."
Fix the judging criteria before the hackathon starts. Publish them. Make them specific and weighted. Something like: Technical ambition (25%), Potential impact (25%), Polish and presentation (25%), Creativity (25%). Judges score each category independently. Totals determine the winner. This isn't perfect, but it's miles better than vibes-based deliberation.
Better yet, use multiple judging panels. A technical panel of senior engineers. A product panel of PMs and designers. A "people's choice" vote from all participants. Different panels often pick different winners, and that's fine — multiple prizes mean more teams feel recognized, and the political pressure on any single panel drops dramatically.
The Logistics of Feeding Developers for 48 Hours
Nobody talks about food logistics until the hackathon is happening and forty developers are hangry. Food is not a detail. Food is infrastructure. Hungry people don't innovate; they complain and then order DoorDash individually, which defeats the communal energy you're trying to create.
The minimum viable food plan: good coffee available continuously (not the pod machine — real coffee), substantial lunch both days, dinner on day one, breakfast on day two, and a continuous snack table that includes things with actual nutritional value alongside the obligatory chips and candy. Budget for this. If your hackathon budget doesn't include food, your hackathon budget is wrong.
The non-obvious thing: dietary restrictions in a group of 50-300 are not edge cases. They're a significant percentage of your participants. Vegetarian, vegan, gluten-free, kosher, halal, nut allergies — collect this information during registration, not when the food arrives. (This is one of those accessibility details that separates thoughtful events from careless ones.) A developer with celiac disease staring at a table of pizza and sandwiches isn't having an innovative afternoon.
Remote Participation Without Second-Class Citizens
The temptation is to say "hackathon is in-person only." This is easier to organize and it's also a great way to exclude your remote employees from the one event they'd actually enjoy. If your company has remote workers, your hackathon should include them, which means actually designing for hybrid participation rather than bolting a Zoom link onto an in-person event.
Remote hackathon participation works when teams are either all-remote or all-in-person. Mixed teams where three people are in a room and two are on a call always produce the same outcome: the remote people become spectators. If you allow mixed teams, require that all collaboration happens in shared digital spaces — chat, shared docs, screen sharing — so the remote participants aren't hearing muffled conversations from a laptop mic in the corner of a conference room.
Demo day is where remote inclusion either works or visibly fails. Give remote teams the same demo time, the same screen access, and the same judging criteria. Schedule them in the main flow, not as an afterthought. "And now let's hear from the remote teams" at the end of a two-hour demo session, when everyone is tired and checking out, is not equitable judging. It's a participation trophy.
Kagibag handles hackathon logistics cleanly: team registration and formation, participant profiles (including dietary restrictions and t-shirt sizes, because someone will ask), schedule management across the 48-hour window, and check-in for demo day. The attendee data collection during registration means you have dietary info, team assignments, and emergency contacts in one place.
Post-hackathon, the follow-up campaign tools help you capture momentum — survey participants, share winning presentations, and start the conversation about which projects deserve continued investment.
Demo Day: Five Minutes of Glory
Demo day is the event within the event, and it requires its own planning — similar to running a product launch for an audience with opinions. The universal mistake is not enforcing time limits. Every team thinks their project needs 15 minutes to explain. No project needs 15 minutes to explain. Five minutes per demo, hard cutoff, with two minutes for questions. Appoint a timekeeper who isn't afraid to cut people off. Developers will thank you — everyone hates sitting through 20 long demos except the people giving them.
The demo order matters more than you think. Put a strong demo first to set energy. Put another strong one right after lunch when attention dips. Don't put all the remote demos at the end. Alternate between different project types so the audience doesn't zone out watching five consecutive data pipeline improvements.
Prizes should be meaningful, which doesn't mean expensive. A day off. The winning project gets engineering time on the roadmap. The team gets to present at the next all-hands. Budget to actually ship the prototype. These prizes signal that the hackathon matters to the organization, not just to the participants. A $50 gift card says "thanks for playing." Protected engineering time says "we take this seriously."
What Happens Monday Morning
The dirty secret of internal hackathons is that 90% of projects die on Monday morning. People go back to their sprints, the prototype sits in a repo nobody visits, and by the next hackathon everyone has forgotten what was built at the last one. This isn't a hackathon problem — it's an organizational follow-through problem.
If you're going to run a hackathon, commit to a post-hackathon process. Within a week: document every project (even the ones that didn't win). Within two weeks: leadership reviews the top projects and makes a decision — ship it, shelve it, or schedule follow-up work. Within a month: teams with greenlit projects have allocated time to continue.
This follow-through is what turns hackathons from morale events into actual innovation programs. Without it, you're spending significant time and money on a two-day team-building exercise. Which isn't worthless — but it's not what you promised when you pitched "48 hours of pure innovation" to leadership either.