The Hackathon Organizer's Playbook: Planning, Sponsors, Visibility, and Judges

You can tell within the first hour of a hackathon whether it was planned or improvised. The wifi either holds up or it doesn't. The judges either know the rubric or they're inventing one at the table. The prizes are either things winners can use next week or things left on a chair. None of that is luck. It's a sequence of decisions made weeks before anyone opens a laptop.

I've spent over fifteen years building and scaling identity infrastructure, which puts me on both sides of the hackathon table often: judging, sponsoring, and occasionally organizing. This is the playbook I'd hand a first-time organizer. It covers how to plan the twelve weeks before the event, how to pick and pitch sponsors, and how to get the event found on Google and cited by ChatGPT. It also covers how to market it on a campus, how to pull in more developers than a mailing list alone reaches, and how to find judges who make the closing ceremony feel earned instead of arbitrary.

The twelve-week shape of it

Work backward from the event date. Two things fall apart most often when organizers skip this: sponsor outreach starting too late to close, and judges recruited the week before with no time to brief them properly.

Selecting and reaching out to vendors

Sponsorship is a marketing line item for the vendor, not a donation, and the pitch works better when you treat it that way. A challenge track puts their API in front of builders who might use it for years. A judging seat gives their engineers a reason to show up in person. A named mention in your recap post is a backlink and a case study they didn't have to write themselves.

Vendor categories that reliably say yes: cloud and AI API credits, identity and auth platforms (several run formal, documented hackathon-sponsorship programs, not just a free tier), developer infrastructure, and communications or payments APIs with developer-marketing budgets. Large non-tech enterprises sponsor too, usually out of community-relations or social-good budgets rather than developer marketing, which means the pitch deck should look different: less "adopt our API," more visible community impact.

Structure the ask before you send it: title, track, infrastructure, or community tier, each with a specific dollar amount or credit level and a specific list of what the sponsor gets back. Vague asks get vague answers, or no answer. The full breakdown, vendor by vendor, with an outreach timeline and sponsor-tier table, is in the hackathon sponsorship guide.

Getting found on Google and cited by ChatGPT

Most organizers treat their event page as a ticket form and wonder why nobody finds it next year. The page dies the moment registration closes, because it was never built to be found, only to collect signups.

The fix is the same handful of moves every time. Use one canonical URL for the event series instead of a fresh one each year, and keep Event schema markup (structured data that marks the date and location up for search engines) current. Add an FAQ section that answers what people actually search, and publish a recap within 48 hours naming the winners and what they built. Ask ChatGPT or Perplexity "best AI hackathons in the Bay Area" and watch what gets cited. It's rarely the ticket-vendor listing. It's a page that reads like a source because it has a real date, a real location, and named people attached to it.

The full breakdown, including working schema code, is in the hackathon event SEO and GEO guide.

Local marketing to universities and schools

If you're running or co-hosting on a campus, the university's own channels outperform anything built from scratch, if used early enough.

Go to the CS department directly, not just the student club. A ten-minute guest-lecture slot or a professor forwarding the announcement to their mailing list reaches students a flyer never will. Student clubs, ACM and IEEE chapters especially (the student branches of the two largest computing and electrical-engineering professional associations), are usually looking for exactly this kind of event to co-host or promote. They already have the Discord or Slack where the target audience lives. The career center is a second channel most organizers skip entirely, even though it exists specifically to forward opportunities like this one to students.

Timing matters more on a campus than anywhere else. Check the exam calendar before locking a date. A hackathon during finals week or the week before midterms loses half its expected signups no matter how good the marketing is.

Attracting more developers

Developers don't discover hackathons the way organizers assume they do. Four channels do most of the work.

• The MLH network, for the same reason it matters for sponsorship: it puts the event in front of an audience that already searches for hackathons, instead of one built from zero.
• Devpost and Luma listing hygiene. Devpost (the project-submission platform most hackathons use) and Luma (a lightweight event-page and RSVP tool). Not the canonical page, but where a meaningful share of first-time discovery happens. A stale or incomplete listing loses signups that never show up as a metric anywhere.
• Developer communities on X and Discord, specifically the ones relevant to the event's theme, not general dev Twitter. A post in a focused AI-agents or security Discord with two thousand relevant members outperforms a generic post to a broad, unrelated audience.
• The alumni loop. Past participants convert better than any cold channel, because they already know what the event is. Email them before the public announcement goes out, and ask them to bring a teammate.

One more lever that's easy to underrate: be concrete about prizes in the announcement itself. "Great prizes" gets skipped over. A specific credit amount across a specific number of named tracks gets forwarded.

Finding quality judges

A bad judging panel is the fastest way to make a well-run hackathon feel arbitrary to the people who put in the most effort.

Source judges from two places. First, practitioner communities in the event's actual subject area, not generalist "startup people." A security-focused hackathon should have security practitioners judging it, sourced from the same kind of focused communities the target participants are already part of. Second, sponsor engineers. They have a real stake in the outcome, and a judging seat is often the single thing they want most out of a sponsorship, ahead of logo placement.

Design the rubric before recruiting judges, not after. Weight technical execution, real-world viability, and presentation as separate, named criteria, publish the weights before the event, and keep the panel to three to five judges per track so no single opinion dominates. For events with more than a handful of teams, a pairwise-comparison judging tool (Gavel is the standard open-source one) scales better than judges scoring every project independently. It reduces judge fatigue and produces more consistent rankings than a straight numeric scorecard past roughly twenty teams.

Day of

Registration and check-in should take under two minutes per person. Longer than that and goodwill is gone before the event starts. If in person, plan power and wifi for hacker density, not conference density: more outlets and more concurrent connections than a typical event of the same headcount. Give mentors a rotation schedule so no track goes unstaffed for hours at a time. Cap demos at 60 to 90 seconds once past roughly fifteen teams. Longer slots feel generous but exhaust the room and the judges both.

After

The recap goes out within 48 hours: winners, what they built, the judging criteria that decided it, photos if there are any. This is simultaneously the sponsorship close-out, the SEO asset, and the thing that makes next year's alumni-email channel worth having. Every sponsor gets a short, specific update: how many teams used their tool, who won their track, a link to the recap. That's what earns a yes next year without re-pitching from zero.

Keep past participants somewhere reachable again, a Discord or a mailing list, not just an Eventbrite export that goes stale the day the event ends. Content and sponsorship earn a first cohort. What happens with that cohort after the event is what turns one hackathon into a series.

Frequently asked questions

How far in advance should I start planning a hackathon?

Twelve weeks is enough for a single-city or campus event: enough lead time to apply to MLH, close sponsors, recruit judges, and run a real marketing push. Larger multi-track or multi-city events need more, mainly for sponsor and venue lead time.

Which sponsor should I approach first?

Major League Hacking, before any individual vendor. Becoming an MLH Member Event is free, unlocks a GitHub Education Grant application, and puts the event in front of MLH's own sponsor network instead of starting every relationship from a cold inbox.

How many judges does a hackathon need?

Three to five per track. Fewer and a single opinion can dominate the outcome; more and scheduling a shared rubric conversation gets difficult. For events past roughly twenty teams, a pairwise-comparison tool like Gavel scales better than independent scoring.

Why does the recap matter so much?

It's the only piece of content from the entire event that search engines and AI answer engines still have something to index a month later. It's also the sponsor close-out and the thing that makes an alumni list worth emailing next year. Publish it within 48 hours, not weeks later.