I organized my first hackathon, and I was doing it (almost) alone which means I tested all aspect of it and learned a lot the hard way. I am sharing my notes.
Sections
Select great event co-organizers
Pick a theme
Prepare materials for hacking
Choose a venue
Select great speakers
Select great judges
Ensure the best experience for speakers and judges
Create an event page
Get relevant attendees
Promote the event
Get prizes
Get food
Create a scoring system
Handle operational tasks
Handle the start of the event
Announce winners with style
Post-hackathon marketing
After-hackathon communication
Do it all again, but better.
1. Select great event co-organizers
Companies usually co-host hackathons with 1-2 other companies. If one person handles the preparations, it’s almost a full-time job. And I think the day of the hackathon requires at least four organizers for it to go smoothly. Pick your team in advance so you don’t have to ask your teammates for help last minute.
I see three types of partnerships for hackathons.
Co-organizer - a company that really helps you with the organizational tasks
Sponsor - a company that pays you to appear on the promotional materials, maybe gives a talk but isn’t involved in preparations
Partner - something in between, depends.
We had a co-organizing company. How to choose a co-organizer (or sponsor or partner)
It’s good to aim for a “bigger” name than yours. Attendees often pick hackathons based on the organizing companies.
Establish clear communication channels with all co-organizing partners. It can be Slack, Discord, WhatsApp group, or whatever.
Define roles and responsibilities for each co-organizer. It’s good to manage expectations because I heard about many cases where some companies just put their name on the event and then you couldn’t rely on them for anything.
2. Pick a theme
One of the eternal struggles of hackathons is getting a relevant crowd of developers to attend. At least in San Francisco, there are a lot of professional event-goers. You can spot these people at every tech meetup or hackathon, they usually show up to eat the food, talk a bit (usually about their new business idea that’s changing every month), and disappear again.
To avoid people who only attend for their own promo, free food, or hiring other attendees, you need to target the right crowd. You will make this much easier if you specify the theme of your hackathon, and give it a bit of “soul”.
Pick a cool hackathon name. It should give people at least some idea of what they should build there. Also, I recommend mentioning the word “hackathon” in the name, if you want to get your event featured in event websites or newsletters. That helps quickly distinguish that the event isn’t just a meetup. For example, our event was called "Hackathon: Code Interpreting 2.0". If you have something to brag about (e.g., one organizer is a really big name), you should put it in the name too.
Add sub-categories if you want. Some hackathons make attendees pick one out of 3-5 specific directions when they register. For example, for AI agent-themed hackathon, it can be sub-topics like “voice agents”, “coding agents”, or “agent evals”. By encouraging people to pick categories, you make them more engaged and create a sense of commitment before the event.
The theme should reflect the field or techstack used.
As an exercise, check out how well you understand what should you build if you attend the following hackathons:
3. Prepare materials for hacking
You might disagree, but I recommend doing this very early on. Otherwise, you can leave preparing the materials at the last minute.
Create “starter pack” page for participants. It can be a Notion page with important links (e.g., where to find API keys), or link to your Cookbook.
Prepare starting templates. These can be simple hello-world examples, but ideally more interesting projects showing how to use your product.
Prepare product credits for participants. If you don’t have a sufficient free tier, it’s a nice gesture to provide free credits for participants to use your product. Don’t forget to inform the hackers how to get their credits. For example, put a form on the page with resources.
4. Choose a venue
The venue gives your hackathon the atmosphere and sets the mood. I would look for a venue that shows a bit of professionalism and a bit of informal hackerish vibe.
Utilize your contacts. If you can’t get a free venue, it is going to be one of the biggest line items in your total budget. However, you can get a “venue sponsor” - an organization or company providing the venue in exchange for promotion or other benefits. VCs often provide their offices for events, and in exchange, they have access to interesting people at the event.
Check if the venue ticks all your boxes. For example:
Can it accommodate your desired number of attendees?
Does it have good-running wifi?
Would the opening hours match the event?
Ensure the venue can accommodate all planned activities.
Is there a way to show demos, speak loud, or record the demos?
Is there a separate space for speakers and judges to store their things?
Have a backup venue option. To mitigate potential cancelation, it’s always good to check out more options.
Decide about starting and ending time. To decide about what time the hackathon starts is one critical decision. There is a tradeoff between people not coming because the start is too early, and people not having enough time for hacking. For the next time, I would announce the start at 8:30, lightning talks at 9:30, and hacking starting at 10:00. Only a portion of people come on time, so you need to have big enough time window for welcoming everyone, but at the same time, you want to have the introduction and lightning talks during breakfast. Similarly, you don’t want the event to end too late, and you need to keep a time reserve because everything always gets delayed. I recommend to plan the end around 7 PM, and still counting with additional hour or two just in case. Don’t forget to check opening hours with your venue.
5. Select great speakers
There is one significant challenge to consider. It doesn’t matter how interesting the demo is; if it’s the third demo in a row, people may start to feel restless or check their phones.
Decide whether speakers should pay. Most hackathons I’ve seen make speakers (sometimes also judges) pay for their spot. We didn’t go this way because I at my first hackathon I didn’t feel entitled to require a sponsoring fee for a speech.
Don’t select random speakers. It’s best when the talks match the theme. I tried to contact people who:
Work on a developer tool that complements our product and attendees can use it during the hackathon.
I already have a connection with and want to strengthen our relationship.
Promote the speakers. It’s indeed great to get “big names” as speakers because for the attendees meeting them can be additional reason to come. You should introduce the speakers on social media and give them enough recognition.
6. Select great judges
Judging a hackathon is not such a desired role compared to being a speaker. I think it's because:
It takes more time. Speakers need to just prepare a demo, which they often already have. The lightning talks are usually 5-10 minutes long only. Judges need to evaluate multiple teams, and often watch many demos, so it
takes several hours at least.
Speakers get more fame. Speakers get the chance to promote their company or project.
The main incentives I’ve seen for judges were:
They need O1 US visa. For this kind of visa, you are essentially proving to US that you are extraordinary alien, and judging hackathons can help you a lot in one of the criteria. I had several people who reached out to me because they wanted to judge for exactly this reason. That’s completely alright though, it usually means those people are kind of good in their job and interested in tech.
They want to promote their services, community, etc. I think that’s also fair. If people want some recognition and are willing to put in some effort, why not?
They just enjoy it and want to network. I had several great judges like this. They just enjoyed judging and were really great at it.
I noticed two big challenges with judges:
Cancelling last minute. Hackathons are often on weekends, and it’s probably not the top social life choice for spending Saturday night. This can happen and you can’t do much about it. My advice is to have enough judges such that you would be okay with losing 2-3 of them, and show them that the event is very professional and serious such that they feel the social pressure not to cancel.
Not putting effort into their job. Most hackathon participants obviously try to win. They notice how judges evaluate their solutions, and if they see a judge who doesn’t pay attention enough, or goes to check only 30% of teams, they won’t be happy. You should be strict towards judges and ensure that they put effort into evaluating.
7. Ensure the best experience for speakers and judges
I have a lot of space for improvement in this. I was super-busy and didn’t always respond fast to every question, I could be more professional towards judges and speakers definitely. These are my learnings:
Show that the event is serious and professional. Judges and speakers need all the information in advance. You
Tell them the exact timeline. It’s almost impossible to stick to the hackathon timeline. However, next time I want to share with speakers not only a half-hour window for when is their speech, but also the order in which they will be talking.
Make the day enjoyable for them. Give them extra conditions. Some speakers were founders of startups and brought more teammates to the event. They gave the talk but spent the rest of the time working together in a separate room, occasionally networking with hackathon attendees. Next time I would explicitly tell speakers and judges that there will be special space for them to have focus time, keep their personal things, etc. I would actively encourage them to bring their team.
Connect judges with other judges. While speakers gave talks on their own, judges naturally formed a close group during the event. It wasn’t easy to pick the best solutions so they discussed their choices a lot. Next time I would encourage this more, e.g., create a WhatsApp or X group before the event so the people can connect with each other.
Give them the credit they deserve. This is super important. I had slides with names, roles, and photos of speakers and judges. I showed that on a big screen so attendees could check who is who. Also, have special name tags prepared for speakers and judges. You can differentiate them by color. Give them a promo on socials before and after the hackathon. Create visuals with their names, post videos, etc.
8. Create an event page
I recommend sticking to a well-established platform for event hosting rather than experimenting with lesser-known options. In San Francisco, Luma is widely used for hosting technical meetups and has become the standard platform for creating events. Here are some reasons why Luma is a great choice:
Great UI. It includes everything: adding co-hosts, sending automatic emails, verifying guests, and more.
Great analytics. You can check the traffic on your event page, how many people are pending, opened e-mails, etc.
Community promotion. Luma has special communities (e.g. “San Francisco”) that have specific subscribers who get new events submitted in that community sent by email. That’s a great way to promote your event.
Be specific in naming. Don’t name it just “AI Agent Hackathon” or “AI Hackathon” or just… “Hackathon”. The big danger of hackathons is people who just randomly come to hackathons without being that interested in the topic. More niche = better. I named ours “Code Interpreting 2.0 Hackathon”. Yes, still not the most creative name, but at least it’s not that generic.
Fill in the description with incentives. Mention prizes, speakers and judges to meet, what can people learn at the hackathon, show the venue if it’s nice, and show examples of how to use the tech stack from the hackathon theme.
Make it legit. There are many events in San Francisco and a lot of noise. You better show your event is professional. Have a nice design with all the logos. Have nicely written and structured copy without mistakes, and with all the information.
Don’t forget the details. I often forget details, so just to remind you about important details specific to Luma events:
Check that the event is set to public.
Check if the waitlist is on. If it’s off and you have maximum capacity set, additional people can’t get on the waitlist and you lost them completely.
Mention that the hackathon is in-person only (if it’s true).
9. Get relevant attendees
This one is tricky and I was told by more people that it’s challenging to filter out irrelevant people. I think 80 - 100 serious hackers is optimum but indeed depends on your capacity and ambition.
That is, people who only come for free food, people who try to advertise their own business, or people who are trying to hire someone. Basically anyone who won’t submit a solution and isn’t an organizer, judge, or speaker.
Some organizers use their own AI filtering mechanism for applicants, some don’t filter them much. I did it manually by checking each person who applied. That cost me a lot of time and people started joking about me being too strict, but in the end, was worth it.
Here are some hints for filtering out people and getting the best crowd.
Define criteria for relevant people. For me, this meant 1) people who appear to be in San Francisco (e.g., have a city in their LinkedIn bio) and 2) people who appear to be technical (e.g., aren’t VCs, even though there are exceptions).
Send additional messages to “suspicious” people. Even with my criteria, I didn’t automatically reject almost no one. If someone seemed to not check these two boxes, I sent them a message, asking if they were really in town, and going to compete in the hackathon. I did this two times minimum, so if someone cared about the event, they usually confirmed and got in. One example is people who live outside of California, but are traveling there just for a few days. I also sent all the “suspicious” people a group e-mail, asking them for a last chance to provide more info.
Create a registration form. I asked people for X, LinkedIn, and GitHub profiles. They often filled in only 1-2 out of these three, but it was often enough to check whether they complied with the criteria.
Increase the probability of registered people actually attending. Prepare good e-mail blasts sent to confirmed people before the event. Create a sheet where they can connect with other attendees and make a team before the event. For next time I have even more ideas for how to make people committed before. For example, they can be asked to share some rough ideas for their hackathon project during registration.
Some of the indications you managed to get a good crowd:
People are just hacking. Most people are focused and fully engaged. Not networking, not wandering around.
You have legit submissions. We got around 1 legit submission per 4 attendees. I am not sure what’s the usual ratio, but I think this isn’t bad.
10. Promote the event
For the previous section, you need to make enough promo for your event to achieve the critical mass of people to choose from. The dynamics is usually most people signing up 2-5 days before the event. However, don’t count on that, and promote the event consistently.
Seek features on relevant industry event calendars and newsletters. If you pick Luma as a platform, you can submit to relevant Luma calendars. It’s free, you just need to have a verified Luma profile (=profile photo and personal information on your profile.) People have subscriptions to these calendars so they will get the events via email. Try these:
You can also check out other newsletters, e.g.:
Cerebral Valley. That’s the most popular events page in SF probably. You can get there for free or pay something more to have your event featured in the newsletter.
I also recommend connecting with Michelle Fang who has a big reach and is known for promoting events on X. She takes events from Cerebral Valley anyway so it’s a great chance that she mentions your event if you submit it there.
Engage judges and speakers in event promotion. Send e-mail with personalized instructions and promotional guidelines to judges. From my experience, most of them won’t promote anyway, but you can incentivize them by tagging, and by creating personalized visuals with their photo and bio.
11. Get prizes
Prizes are tricky because people already have everything. I thought our prizes were nice, we provided product credits, and hardware tech gadgets like the best-rated noise-canceling headphones or mechanical keyboard. However, based on feedback the prizes could be better. How to think of something original?
Consider a mix of cash, product credits, physical prizes, or experiences. Product credits make people use your product. Cash is always good, personally, it would probably make me the happiest. Physical prizes and experiences leave a nice memory, and you can make the best content with them. By “experiences” I mean something like dinner with the organizing team or a mentoring session with one of the speakers.
Get enough items for teams, not individuals. Some teams pointed out that they can’t really divide one hardware prize between 2 or 3 people. That was the average team size at our hackathon, and I recommend having prizes planned such that you can distribute them among more people.
Let the first team pick the prize. Even if some prizes cost more than others, I think the best strategy is to let the best team pick, then the second, etc.
12. Get food
Food. The alpha and omega of every event. I have made a few events (apart from this hackathon) and there was always someone complaining about food and drinks. People usually want MORE FOOD. One mathematical theorem says that if you prepare x amount of food, people always require x + 1.
However, we got excellent feedback on our food choices. It was healthy, tasty, and most importantly, it was not pizza.
What we had:
Bagels and coffee for breakfast (our CEO Vasek loves Noah bagels)
Hummus, pita, and salad for lunch
Spring rolls and chicken wings for dinner
Bananas for snacks
Here are some tips:
Healthy food is good. Yes, pizza is probably lower cost per volume, but healthy = cool, at least in San Francisco.
Food was eaten quickly. Some people weren’t fast enough and were too focused on hacking. Next time if I have enough time I want to occasionally bring food to the hidden corners of the venue such that everyone can get something. There was also one person who couldn’t find the food for some reason.
Consider dietary requirements. You don’t have to get something for every single intolerance and allergy, but it will definitely be appreciated if you have at least a vegetarian option.
It’s good to inform people which food is vegetarian, vegan, gluten-free, dairy-free… I had a person come to me in the middle of everything and kindly ask me to identify which bagels were without meat. I knew most were, but I haven’t separated them or given this problem more thought so I couldn’t answer at that moment. Next time I will make this explicit, e.g. add colorful labels to different dietary restrictions.
13. Create a scoring system
A question to discuss is how to evaluate people’s submissions. Even though it’s always a bit subjective, it needs to look fair and well-thought. Evaluation of the submissions and announcing winners is one of the key parts of the hackathon. Don’t fuck it up.
Create a shared scoring sheet. I used Google Sheets where all judges had access.
Create a submission form. I used Google Forms where every team had to write their team name, description of what they built, link to the code, and identification of their team - e.g., where they sit and how to find them. This was important for judges in order to consult the teams on their solutions.
Have two rounds. This has one reason, and that is to save time on the demos. I wanted to have a finale where teams present their solutions, but if each takes around 5 minutes, you could easily spend hours on that. That’s why I made the first round where each judge picked their top 6 teams in the Google sheet. In this first round, they evaluated both the technical aspect and team vibes by walking around and consulting the teams in person. During the consultation person (~1 hour) teams still could continue hacking. Then top 6 teams were selected for the final round to present their demo. (In fact, we ended up selecting 8 teams because there was a tie situation after the first round). We had 20 submissions, so if we let everyone present, people would probably start leaving.
Have multiple judging groups. This is an alternative (or a complement) to having multiple rounds. Some people told me that they divided judges and teams into groups and let each group of judges assign scores to only part of the teams. That way that saved time and made judges more focused. I didn’t go this way because I was worried that it would end up too chaotic with too many instructions.
Don’t overcomplicate it. You want to prevent chaos and mistakes, and there might be judges who won’t read instructions in advance or who don’t understand some details.
Mix objective and subjective criteria. Our objective criteria was using our own product. This, plus having a functioning code, were the necessary conditions for winning. Other criteria were a bit more subjective - judges gave rating based on their own personal preferences. Good thing is, they often agreed.
Create a good point system. We had a binary system for first round (just check your top 6 teams) and 1-4 point system for the finale. I think simpler is better.
Consider adding bonus points for specific challenges. If you want to be more creative, you can add mini challenges, e.g. bonus points for using a specific tool.
One last tip is to call the judges into one room during the day and go with them through the scoring rules. Of course, you need to send them the instructions before the event, but everyone is busy, and it’s best to summarize everything in person.
14. Handle operational tasks
Let me tell you I do not enjoy these AT ALL.
Secure appropriate event insurance. Our venue (Edge Network) had a fantastic handbook prepared for organizing events, so they told me I should get insurance, which I wouldn’t have realized without them. Just use Perplexity to search for one-day event insurance in your city. Our cost was something like $70.
Get janitors. I got one lady cleaning and distributing food and drinks from 1 PM to 9 PM. It was enough to leave the space as it was before. Next time I would probably call someone in the morning so I can save time preparing everything myself.
Get security. I didn’t do this, but some venues might require that.
Prepare for people entering the building. Make sure people know how to enter the venue, that it’s not locked or they know who to call if it is. I think the best strategy is to have at least one person at the door, at least for saying hi. If there is someone at the reception, you need to ensure that they know about the event and will let people in. I let this for the last minute.
Plan catering in advance. You can use catering services like EzCater in San Francisco. Don’t rely on Uber Eats, they might not handle bigger orders.
Buy office supplies. You will need name tags for registrations, markers, papers, and more. One nice trick we had is different-color name tags based on the role (e.g., one color for attendees, one for judges, etc.)
15. Handle the start of the event
You need more people helping you on the spot than you might think.
Prepare registration well. The morning was the most stressful part for me because everything was happening at once. People start coming, everyone asked questions, speakers, judges, and friends came to greet me, so I was just running around and panicking. For registration, it’s good to have two people minimum. One person to check whether newcomers are approved on the Luma page, another one to give them name tag. Ideally, I would have a third person who would then direct the hackers towards breakfast and coffee and chit-chatted with them a bit.
One person should be focused content and talking. It’s difficult to be a good moderator and at the same time having to run around and fix fuckups. It’s good that at least one person is relaxed and can transfer this mood to the attendees.
Have technical needs tested the day before. You should ensure that internet runs well, that there is a way to connect your laptop, microphone works, etc. It’s good to have USB with a timeline slide that you can project on a wall or second screen all day, while you present demos and lightning talks on your main screen.
Designate specific areas for different activities. There should be enough space for teams not to be stacked too close to each other, but there should also be a separate space for judges and speakers to leave their things, brainstorm together, or do their own work during the day.
Announce everything more times. Even if you just said something, it is sometimes followed by a question asking exactly the thing you just said. Prepare that you will have to repeat when to submit solutions, when’s the lunch, or that the lightning talks are starting.
Have the lightning talks during eating. It’s good trick to catch people’s attention. We had first few talks during breakfast, and second half of them during lunch.
16. Announce winners with style
When finalists are selected, you need to be a moderator for their demos.
Have judges seated in the first row so they can easily ask question.
Set a timer for each team. We had 3 minutes for demo and two minutes for audience questions.
Have a moderator who can make a show. Our team is quite introverted, but it’s still good to give the microphone to someone who is enjoying the job.
Stream the finale. We had one person who has a YouTube channel and started live streaming the demos. I think it was a fun idea.
Don’t forget to take videos and photos of everything. People will ask to see the demos from your hackathon, and to check out photos. Have someone on your team who is ready to record and has at least a good-quality phone.
17. Post-hackathon marketing
Create comprehensive post-event communication with all stakeholders. It can be a X (Twitter) thread with finalists’ demos, a thank you for speakers and judges, ideally a lot of videos, photos, and description of what people built.
Send a group email to attendees. Add all resources and next steps, e.g., what they can build with your product and where to follow you. Don’t forget to ask them for feedback!
18. After-hackathon communication
Try to thank all speakers, judges, organizers, and venue sponsor for attending, and ask them for feedback. Share with them the social media posts you created so they can share and support. Collect and analyze feedback from all stakeholders.
19. Do it all again, but better.
Collect and analyze feedback from all stakeholders. Be tired. Say that you are never going to organize this again. Write up learnings. Then do it again. :)
I want to really thank these people for helping with the hackathon:
Casey Aylward shared her experience with getting relevant attendees, scoring criteria & much more
Mikiko Bazeley helped lead the event, get publicity for it & give it a soul
Adam Silverman shared overall experience with hackathons
Alessio Fanelli helped with venue recommendations
Era Quian helped with venue, operations, and one time even becoming a Spanish translator for me
Vasek Mlejnsky - my partner in crime, helped with all the strategic decisions and was always here to share his opinions and help
& others.
Thank you, you are heroes!